Bug 65336 (Travis)

Summary: Blank labels in multi-threaded Jmeter tests
Product: JMeter Reporter: travis.mcginley
Component: MainAssignee: JMeter issues mailing list <issues>
Status: NEW ---    
Severity: major CC: travis.mcginley
Priority: P4    
Version: 5.4.1   
Target Milestone: JMETER_5.5   
Hardware: PC   
OS: All   
Attachments: Result Tree with blank labels
Test plan
Log File
Simple plan (that doesn't show this)
Test Schematic
Minimal plan to reproduce
Skip NAME when marking temporar props
Don't mark enclosed properties of TestElementProperty as temporary

Description travis.mcginley 2021-05-27 15:36:44 UTC
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.
Comment 1 Felix Schumacher 2021-05-27 16:12:35 UTC
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?
Comment 2 travis.mcginley 2021-05-27 16:39:02 UTC
Created attachment 37880 [details]
Test plan

Test plan showing which the requests that have their labels disappearing after some time.
Comment 3 travis.mcginley 2021-05-27 16:39:34 UTC
Created attachment 37881 [details]
Log File

Log file from most recent test.
Comment 4 travis.mcginley 2021-05-27 16:46:22 UTC
(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.
Comment 5 Felix Schumacher 2021-05-27 17:10:06 UTC
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.
Comment 6 travis.mcginley 2021-05-27 17:58:11 UTC
Created attachment 37883 [details]
Test Schematic

Schematic of test plan
Comment 7 travis.mcginley 2021-05-27 18:00:20 UTC
(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.
Comment 8 travis.mcginley 2021-05-27 18:10:03 UTC
(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.
Comment 9 Felix Schumacher 2021-05-30 10:15:31 UTC
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?
Comment 10 travis.mcginley 2021-06-02 12:39:27 UTC
(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.
Comment 11 Felix Schumacher 2021-06-03 08:46:47 UTC
Created attachment 37886 [details]
Minimal plan to reproduce

Thanks for the further information. I can now reproduce the problem and will investigate further.
Comment 12 Felix Schumacher 2021-06-03 11:36:32 UTC
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.
Comment 13 Felix Schumacher 2021-06-03 13:25:55 UTC
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.
Comment 14 Felix Schumacher 2021-06-06 11:28:46 UTC
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.