Hi, With the latest release of Jmeter 2.13, I see SSL handshake is being done for each sample HTTPS request, which suggests that the cached ssl context is not being used. Following properties is also set in the jmeter properties file. https.use.cached.ssl.context=true As can be seen from the below log file, in 2.13 close is being called twice for 2 HTTPS samplers 2.13 - dubug info of ssl connection 1_11_PerfomanceTestSuite_SingleUser 1-1, called close() 1_11_PerfomanceTestSuite_SingleUser 1-1, called closeInternal(true) 1_11_PerfomanceTestSuite_SingleUser 1-1, SEND TLSv1.2 ALERT: warning, description = close_notify 1_11_PerfomanceTestSuite_SingleUser 1-1, called closeSocket(selfInitiated) 1_11_PerfomanceTestSuite_SingleUser 1-1, called close() 1_11_PerfomanceTestSuite_SingleUser 1-1, called closeInternal(true) 1_11_PerfomanceTestSuite_SingleUser 1-1, SEND TLSv1.2 ALERT: warning, description = close_notify 1_11_PerfomanceTestSuite_SingleUser 1-1, called closeSocket(selfInitiated) As can be seen from the below log file, in 2.11 close is being called once for HTTPS samplers 2.11 - dubug info of ssl connection 1_11_PerfomanceTestSuite_SingleUser 1-1, setSoTimeout(10000) called 1_11_PerfomanceTestSuite_SingleUser 1-1, called close() 1_11_PerfomanceTestSuite_SingleUser 1-1, called closeInternal(true) 1_11_PerfomanceTestSuite_SingleUser 1-1, SEND TLSv1.2 ALERT: warning, description = close_notify 1_11_PerfomanceTestSuite_SingleUser 1-1, called closeSocket(selfInitiated)
Hi, Can you confirm you don'tget same behaviour with 2.12 ? Can you put jmeter in debug and send log file ? Can you attach your test plan ? Thanks
Hi, I tested with 2.13 and it works for me. For a Test Plan that runs 10 samples to same HTTPS URL and 1 user: - If I set https.use.cached.ssl.context=true, I get 1 handshake *** ServerHelloDone - If I set https.use.cached.ssl.context=false, I get 10 handshakes *** ServerHelloDone Note that you must use HTTPClient 4 or 3.1 Closing as it works for me, feel free to open with more details.
I just ran into the same problem and did a little analysis: It happens with the HC4 sampler (don't know about the others) when used with client certs. HC4 uses a pool that compares two things to find an adequate connection: the HttpRoute (target host, proxies etc.) and a "state" Object. If the state Object is null, then HC4 will only return a connection who's state is also null. If it is not null, the state of the connection must have the same state value. Now state is not something like closed or opened or so. Instead by default if no state is present, HC4 determines a state at the end of the request using a UserTokenHandler. The default UserTokenHandler will set the state of a connection at the end of the request to the value of the client cert used in the SSL session. But JMeter always requests a connection with null state value, so a previously used connection will never match, I don't have a fix ready, but since currently the requested state - null - and the state a connection is set to after use - the client cert - never matches, we either need to make sure, that we request a connection for the correct state, or that the state of a connection is not set or set to a stete we use when requesting the connection. Example: Set the state to something sensible before running the request: the state can be injected using localContext.setAttribute(ClientContext.USER_TOKEN, "dummy"); in JMeter HTTPHC4Impl between creating localContext and calling executeRequest(). HC4 will then take the state from the context and not try to determine it using the SSL Session. For the first request, a new connection has to be created and when it is released is will be branded using the provided state. Next time we need a connection, if we ask for the same state, we will get the same connection back. So if we have a good concept of the correct state Object, we could fix it that way. So far for now.
@Vividh: are you also using client certificates?
Something like the key alias would be a good state object. Don't know whether that's easy to get and use in HTTPHC4Impl.
Yes, I am using client certs (self signed).
Renaming to make the bug clearer. Also removing the "regression" qualification as it does not appear to be a regression.
Author: pmouawad Date: Sat Dec 26 23:06:17 2015 New Revision: 1721771 URL: http://svn.apache.org/viewvc?rev=1721771&view=rev Log: Bug 57804 - HTTP Request doesn't reuse cached SSL context when using Client Certificates in HTTPS Bugzilla Id: 57804 Modified: jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java jmeter/trunk/xdocs/changes.xml
Created attachment 33374 [details] Test plan used
Created attachment 33375 [details] Logs of 3 test Using the Test Plan , see the logs for: - 2.13 - 2.14 pre fix - 2.14 post fix Log files are named using: - client-cert suffix relates to ClientCert being enabled / NoClientCert being disabled - no-client-cert suffix relates to ClientCert being disabled / NoClientCert being enabled
Author: pmouawad Date: Wed Dec 30 15:26:19 2015 New Revision: 1722352 URL: http://svn.apache.org/viewvc?rev=1722352&view=rev Log: Fix NPE during recording Bugzilla Id: 57804 Modified: jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/3580