Session/Cookie handling bug in soapUI 4.5.1
I'm trying to upgrade to soapUI 4.5.1 but I'm running in to problems concerning the handling of Cookies. All test cases use the "Maintain HTTP session" setting since we rely in part on using the JSESS...
Forum Discussion
I observed also HTTP session is no longer properly maintained in recent versions of soapUI. I tested with 4.5.1 and the latest nightly build, all with the same results.
There seems to be one HTTP session shared by all threads. I created a testcase (attachment) to demonstrate this behavior. I checked "Maintain HTTPS Session".
I created a webservice that creates a session. Subsequent calls report the number of times this particular session
has been used. This public service is (temporary) available at http://d4cca2c7.cm-2.dynamic.ziggo.nl:8 ... ount_calls.
If you call it in a browser the behavior can be checked by using <F5>.
I call this service twice in the testcase: the first time the times_uses should be 0, the second time is should be 1. The single testcase is successful, but the loadtest with multiple threads fails big time! The same session cookie is used for all calls by all threads. A small improvement can be made by dropping the cookie in the first test step, but I don't think that should be necessary.
There seems to be one HTTP session shared by all threads. I created a testcase (attachment) to demonstrate this behavior. I checked "Maintain HTTPS Session".
I created a webservice that creates a session. Subsequent calls report the number of times this particular session
has been used. This public service is (temporary) available at http://d4cca2c7.cm-2.dynamic.ziggo.nl:8 ... ount_calls.
If you call it in a browser the behavior can be checked by using <F5>.
I call this service twice in the testcase: the first time the times_uses should be 0, the second time is should be 1. The single testcase is successful, but the loadtest with multiple threads fails big time! The same session cookie is used for all calls by all threads. A small improvement can be made by dropping the cookie in the first test step, but I don't think that should be necessary.
