Created attachment 37879 [details] Result Tree with blank labels When running multi-threaded Jmeter tests, some request labels disappear. It seems that once a thread runs the initial request, the subsequent requests no longer have a label. Please see attached screenshot for an example. This affects the data when generating HTML reports as the results consolidate all requests with no label. This issue is reproducible.
Can you supply a minimal test plan to reproduce this? What do you mean with multi-threaded JMeter tests? How do you set the labels?
Created attachment 37880 [details] Test plan Test plan showing which the requests that have their labels disappearing after some time.
Created attachment 37881 [details] Log File Log file from most recent test.
(In reply to Felix Schumacher from comment #1) > Can you supply a minimal test plan to reproduce this? > > What do you mean with multi-threaded JMeter tests? > > How do you set the labels? Hi Felix, thanks for reaching out. I attached additional images and files to help assist with the problem. One image shows the test plan that is executed. What this shows is a thread group "Load" that has an initial request "access_token" that runs only once per thread. The thread group is comprised of 20 users and runs for 900 seconds with a ramp time of 100 seconds. Once the initial 20 threads are created, the portion of the group that loops is "Mfg feature-check", "Mfg send MCF", and "Mfg verify MCF". The first set of requests of these 3 have labels while the subsequent iterations are blank. I set the labels via the "Name" second of the HTTP Request block.
Created attachment 37882 [details] Simple plan (that doesn't show this) Travis, I tried to re-create a plan, that would let me re-produce this, but I failed. Can you try the attached plan and look for differences to yours and may be make it fail, too? (you have to start the mirror server in the test plan) Instead of pictures of a test plan, it would be way better to attach a real test plan, or use the schematic view from the tools menu.
Created attachment 37883 [details] Test Schematic Schematic of test plan
(In reply to Felix Schumacher from comment #5) > Created attachment 37882 [details] > Simple plan (that doesn't show this) > > Travis, I tried to re-create a plan, that would let me re-produce this, but > I failed. Can you try the attached plan and look for differences to yours > and may be make it fail, too? (you have to start the mirror server in the > test plan) > > Instead of pictures of a test plan, it would be way better to attach a real > test plan, or use the schematic view from the tools menu. I will try the test plan you attached. In the mean time, I attached the schematic you requested, for your review.
(In reply to travis.mcginley from comment #7) > (In reply to Felix Schumacher from comment #5) > > Created attachment 37882 [details] > > Simple plan (that doesn't show this) > > > > Travis, I tried to re-create a plan, that would let me re-produce this, but > > I failed. Can you try the attached plan and look for differences to yours > > and may be make it fail, too? (you have to start the mirror server in the > > test plan) > > > > Instead of pictures of a test plan, it would be way better to attach a real > > test plan, or use the schematic view from the tools menu. > > I will try the test plan you attached. In the mean time, I attached the > schematic you requested, for your review. Hi Felix, I was not able to reproduce the problem with the test file you provided.
I can find no real differences rom the attached schematic plan to my attached working plan. Is the problem reproducible with one thread (simulated user)? Can you show the results (in the Results Tree View) of the request before the missing label and the one with the missing label?
(In reply to Felix Schumacher from comment #9) > I can find no real differences rom the attached schematic plan to my > attached working plan. > > Is the problem reproducible with one thread (simulated user)? > > Can you show the results (in the Results Tree View) of the request before > the missing label and the one with the missing label? Hi Felix, I apologize for the late response as I was on vacation. We were able to figure out what was causing the issue. When the HTTP Header Manager has the exact same name of its HTTP Request, this causes the titles of the subsequent threads to appear blank. We are unsure why this is the cause; upon making the Header Manager's name different, the problem no longer occurs.
Created attachment 37886 [details] Minimal plan to reproduce Thanks for the further information. I can now reproduce the problem and will investigate further.
The problem seems to stem from the HeaderManager (and others like the CookieManager) to register their names under the same key in the properties and marking the prop as temporary. Those temporary properties are removed when the testplan is 'pack'ed.
Created attachment 37887 [details] Skip NAME when marking temporar props After further investigations, it seems this is a regression introduced in 2003 by commit 73ac1ed5c3ef9cde27a90e86222ef1f399f78d90. If a JMeterProperty is marked as temporary and it is a MultiProperty, every property of that MultiProperty is marked as temporary in a global Set. This is problematic at least in the case we see here, where one property is the StringProperty with the same key (AbstractTestElement.NAME) and value ("Mfg send MFC"). A simple (but probably not correct) fix would be to skip marking StringProperties with key AbstractTestElement.NAME. That way the plan in this issue works without problems. But we might miss marking properties, that should be cleaned up. I think about adding some kind of scope to the props of MultiProperties, that would allow us to correctly identify the inner props, that are temporary and those, that are not. So, I am glad, that you found a workaround and can hopefully live with it for a while. Changes here should probably not be taken lightly.
Created attachment 37891 [details] Don't mark enclosed properties of TestElementProperty as temporary The inner properties of a MultiProperty are marked as temporary by the AbstractTestElement setTemporary implementation. This is needed, since the MultiProperty default implementation of mergeIn is recursive on MultiProperties. The TestElementProperty does not implement this method recursively and therefore must not have marked the enclosed properties as temporary.
Hi Travis, could you test the next nightly build and check, if it works for your use case? commit 31281636281e03fc3379677b24052fe612e2e7b5 AuthorDate: Sun Jun 6 13:22:37 2021 +0200 Don't mark enclosed properties of TestElementProperty as temporary The inner properties of a MultiProperty are marked as temporary by the AbstractTestElement setTemporary implementation. This is needed, since the MultiProperty default implementation of mergeIn is recursive on MultiProperties. The TestElementProperty does not implement this method recursively and therefore must not have marked the enclosed properties as temporary. Bugzilla Id: 65336 --- .../jmeter/testelement/AbstractTestElement.java | 10 ++- .../testelement/AbstractTestElementSpec.groovy | 99 ++++++++++++++++++++++ 2 files changed, 108 insertions(+), 1 deletion(-)
commit ece61619ce703c71ca9b6c4b4eaee05195d6bebc AuthorDate: Sun Aug 29 11:04:36 2021 +0200 Missing changes entry for Bug 65336 --- xdocs/changes.xml | 1 + 1 file changed, 1 insertion(+)
Closing, as no feedback probably means, it works.
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/5544