Hello, that sounds reasonable, thanks for investigation. Indeed as keepalive close leads to socket close, a new init of ssl context occurs leading to an increase in counter and thus leading to the switch.
Switching to the method using CSV (as proposed by Ubik Load Pack) and variable name should not suffer from this I think. But a confirmation is welcome. Regards On Wednesday, May 7, 2014, RP Schell <[email protected]> wrote: > > We simplified the JMeter plan exhibiting the certificate switching > problem down to one thread doing single request in a loop. > The unwanted certificate switch seems to be related to connection > keep-alive behavior. > We see the certificate change when server closes the connection after > the keep-alive 'max' value decrements down to zero. > > For example, here are (part of) the response headers leading up to > the certificate switch: > > HTTP/1.1 304 Not Modified > Connection: Keep-Alive > Keep-Alive: timeout=10, max=2 > > HTTP/1.1 304 Not Modified > Connection: Keep-Alive > Keep-Alive: timeout=10, max=1 > > HTTP/1.1 304 Not Modified > Connection: close > > ============ NEXT REQUEST IS ISSUED WITH A DIFFERENT CERT =========== > > HTTP/1.1 200 OK > Keep-Alive: timeout=10, max=500 > Connection: Keep-Alive > > On Tue, May 6, 2014 at 6:21 AM, UBIK LOAD PACK Support > <[email protected]> wrote: > > Hello, > > Can you show the structure of your Test ? > > Maybe open a bug with the Test Plan simplified . > > > > Clearly regarding "https.use.cached.ssl.context to true seems to be do > > better", this does not work as it leads to sharing the certificate > between > > users. > > > > Regards > > > > > > On Tue, May 6, 2014 at 12:34 AM, RP Schell <[email protected] > >wrote: > > > >> > >> Thanks for the feedback! > >> > >> Yup, as stated I have tried https.use.cached.ssl.context=false, > >> HttpClient4, and https.sessioncontext.shared=false without success. > >> Setting https.use.cached.ssl.context to true seems to be do better > >> because the user switching does not happen as frequently, but it still > >> happens setting that option to true or false. > >> > >> In answer to your question, we typically put the keystore > >> configuration under the test plan itself at the same level as the > >> thread group that is being defined. The plan itself only defines a > >> single thread group. We have tried putting the keystore configuration > >> under the thread group itself. THIS MAKES NO DIFFERENCE. Putting it > >> at the top level or under the thread group when there is only one > >> thread group defined has the same behavior. > >> > >> I had not tried using the keystore configuration with a CSV data set > >> configuration. Thanks for that suggestion. I tried an experiment > >> with that. The CSV allows the control of the what certificate is used > >> and in what order. However, it does not solve the ultimate problem of > >> JMeter switching users. The CSV data set configuration simply causes > >> JMeter to switch users as defined in the order of the CSV instead. > >> > >> I am seeing a pattern emerge from using the CSV though. Our test > >> users are numbered chronologically (e.g., user0, user1, user2, user3, > >> etc). Every 5 loops through the JMeter test, the user identified is 5 > >> numbers higher than before. For example, the test starts at coming in > >> as user 0. On the 5th looping of the test in that thread group, the > >> user is now identified as user 4, and we start getting errors because > >> the server expected us to still be user 0. > >> > >> Again, it looks like JMeter is switching users on me when it restarts > >> the looping of the test plan. How do we control this. It seems none > >> of the options I have mentioned trying allow for it. Thanks! > >> > >> -Bill > >> > >> On Tue, Apr 29, 2014 at 4:12 PM, UBIK LOAD PACK Support > >> <[email protected]> wrote: > >> > Hello, > >> > As per: > >> > > >> > http://jmeter.apache.org/usermanual/component_reference.html#Keystore_Configuration > >> > > >> > > >> > https.use.cached.ssl.context must be set to false and httpclient4 > must be > >> > used > >> > Don't use: > >> > https.sessioncontext.shared=false > >> > > >> > Also it is much better since 2.11 to use : > >> > Variable name holding certificate aliasVariable name that will contain > >> the > >> > alias to use for authentication by client certificate. Variable value > >> will > >> > be filled from CSV Data Set for example. In the screenshot, > >> > "certificat_ssl" will also be a variable in CSV Data Set.False > >> > Read doc on start and end index to be sure you configure them > correctly > >> > > >> > You speak about different thread groups, where do you put keystore > >> config ? > >> > > >> > Regards > >> > @ubikloadpack > >> > On Tuesday, April 29, 2014, RP Schell <[email protected]> > wrote: > >> > > >> >> Hey everyone, > >> >> > >> >> We are attempting to simulate a large user -- Cordialement. Philippe Mouawad. Ubik-Ingénierie UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/> UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>
