Bug 64618

Summary: JMeter 5.3 Issue with Blazemeter Parallel Controller - Socket closed
Product: JMeter Reporter: singhabhisek <solution.abhisek>
Component: MainAssignee: JMeter issues mailing list <issues>
Status: RESOLVED WORKSFORME    
Severity: normal CC: p.mouawad, solution.abhisek
Priority: P2    
Version: 5.3   
Target Milestone: ---   
Hardware: All   
OS: All   
Attachments: Sample Test Script for the Problem statement

Description singhabhisek 2020-07-21 10:17:38 UTC
Created attachment 37366 [details]
Sample Test Script for the Problem statement

While testing Blazemeter Parallel Controller (0.9) with Jmeter 5.3 version for few https requests in the controller, we are getting the following exception -

java.net.SocketException: Socket Closed 
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
....

We tried the same script on JMeter 5.2.1 or lower versions and it works without any changes/issues. 

Here is the JMeter Plan Structure having issues of socket read - 

Test Plan
+ Thread Group
++ HTTP Sampler Request 1
++ Blazemeter Parallel Controller
++++ HTTP Sampler Request 2 (inside parallel controller)
++++ HTTP Sampler Request 3 (inside parallel controller)
+View Result Tree

In my Test plan, if I keep a HTTP sampler as first request and then  parallel controller having two or more requests , then only the first registered request in that controller will pass and rest will fail in the parallel controller with the error as Socket Closed.

Interestingly, if I change the sequence and the parallel controller was the first request followed by a HTTP sampler or anything - there is no error in JMeter 5.3

However if I change the parallel controller to transaction controller in JMeter 5.3, it is starting to work without issues.

Also attached is a sample test script for reference.
Comment 1 Philippe Mouawad 2020-07-26 15:36:06 UTC
This plugin is a 3rd party plugin.
I suggest you report issue to the project that maintains it.
Comment 2 tdbgauthamkumar 2020-11-16 06:52:03 UTC
This bug is happening in JMeter 5.3 version.
Same parallel controller scripts working when downgraded to JMeter 5.2.1 version.

So, Please fix it as its been a blocker/critical bug for our jmeter performance pipeline where we distribute to simulate millions of users.
Comment 3 Philippe Mouawad 2020-12-19 17:05:54 UTC
(In reply to tdbgauthamkumar from comment #2)
> This bug is happening in JMeter 5.3 version.
> Same parallel controller scripts working when downgraded to JMeter 5.2.1
> version.
> 
> So, Please fix it as its been a blocker/critical bug for our jmeter
> performance pipeline where we distribute to simulate millions of users.

This plugin has IMO, a very hacky approach to do its work:

- Using reflection to access internal jmeter core fields

https://github.com/Blazemeter/jmeter-bzm-plugins/blob/master/parallel/src/main/java/com/blazemeter/jmeter/controller/JMeterThreadParallel.java#L44


- Making Non thread safe core JMeter components "thread safe" by cloning them 

https://github.com/Blazemeter/jmeter-bzm-plugins/blob/master/parallel/src/main/java/com/blazemeter/jmeter/controller/ParallelSampler.java#L338
...


What is happening here is that the Samplers are sharing HTTPHC4Impl#HTTPCLIENTS_CACHE_PER_THREAD_AND_HTTPCLIENTKEY and randomly, one thread triggered by this plugin will close HTTPClient used by another one leading to the problem.


I would suggest you report this issue to the maintainer of this plugin.
It's not because it works with JMeter 5.2 and not in 5.3 that issue comes from 5.3. It's very possible that approach of plugin relied on a hack that does not work anymore.


Anyway, JMeter team is composed of volunteers working on their personal time and sometimes with some "sponsoring".
We spend most of our time on Core and it's quite enough.

As you run millions of users, I guess you can afford paying somebody to dig in this issue to see where it comes from and propose a patch.
Comment 4 Philippe Mouawad 2020-12-19 17:23:01 UTC
I confirm issue is coming from what I wrote.
In JMeter 5.2.1, each thread from Parallel Controller has a different HTTPCLIENTS_CACHE_PER_THREAD_AND_HTTPCLIENTKEY reference which is why issue does not occur
Comment 5 eR@SeR 2020-12-19 17:57:02 UTC
(In reply to Philippe Mouawad from comment #3)
> (In reply to tdbgauthamkumar from comment #2)
> > This bug is happening in JMeter 5.3 version.
> > Same parallel controller scripts working when downgraded to JMeter 5.2.1
> > version.
> > 
> > So, Please fix it as its been a blocker/critical bug for our jmeter
> > performance pipeline where we distribute to simulate millions of users.
> 

> I would suggest you report this issue to the maintainer of this plugin.
> It's not because it works with JMeter 5.2 and not in 5.3 that issue comes
> from 5.3. It's very possible that approach of plugin relied on a hack that
> does not work anymore.

The issue regarding Parallel controller was already reported in the corresponding thread https://groups.google.com/g/jmeter-plugins/c/RgO8DJSQXx8 of "jmeter-plugins" and no one of the maintainers even replied to it :(

@Philippe, if you have time and will, I would ask you to write in the provided thread what you've found as an issue and try to speed the process of fixing it. The controller became totally useless, unfortunately. Thank you.

By the way, the plugin is really useful and used a lot in my functional tests.
Comment 6 eR@SeR 2020-12-19 18:09:16 UTC
If there is a possibility, if maintainers can't or won't work on it anymore, the Parallel controller can become part of JMeter core functionality. Please reconsider this.

It would be a pity that such a good plugin stops its development path. Thank you.
Comment 7 Philippe Mouawad 2020-12-19 18:18:53 UTC
I found the commit that broke the plugin:

https://github.com/apache/jmeter/commit/20bc14513b238f79d6190971e4617ac9c5f88c49
Comment 8 Philippe Mouawad 2020-12-20 20:12:38 UTC
(In reply to Philippe Mouawad from comment #7)
> I found the commit that broke the plugin:
> 
> https://github.com/apache/jmeter/commit/
> 20bc14513b238f79d6190971e4617ac9c5f88c49

This commit is not a bug, it reinstates the correct behaviour that was errouneously removed in JMeter 3.2 and is required for correct handling of Parallel Downloads in JMeter.


The parallel sampler currently uses a subclass of JMeterThread supposed to be per user, so not sharing connections. A browser shares connections for Ajax parallel requests, so the plugin has IMO a wrong approach on this side.

So I close this ticket as now issue is diagnosed and located in 3rd party plugin.
Comment 9 Philippe Mouawad 2020-12-20 20:21:22 UTC
(In reply to Philippe Mouawad from comment #8)
> (In reply to Philippe Mouawad from comment #7)
> > I found the commit that broke the plugin:
> > 
> > https://github.com/apache/jmeter/commit/
> > 20bc14513b238f79d6190971e4617ac9c5f88c49
> 
> This commit is not a bug, it reinstates the correct behaviour that was
> errouneously removed in JMeter 3.2 and is required for correct handling of
> Parallel Downloads in JMeter.
> 
> 

FORGET THIS:
--------
> The parallel sampler currently uses a subclass of JMeterThread supposed to
> be per user, so not sharing connections.
--------

> A browser shares connections for
> Ajax parallel requests, so the plugin has IMO a wrong approach on this side.
> 
> So I close this ticket as now issue is diagnosed and located in 3rd party
> plugin.

The current issue in the plugin is that is ends up calling threadFinished which closes the Connection Manager shared between the threads it triggered.