Session/Cookie handling bug in soapUI 4.5.1

This also happens in LoadUI, which apparently uses SoapUI underneath.

The good thing is that you can check for this by saving off the JSESSIONID value in the context after you get a session, then using a script between each step to compare the value of JSESSIONID to your stored value. If it doesn't match, you can try and force JSESSIONID back to the old one or just jump to your logout handler, or both.

This isn't ideal, but it mostly works.

I'm curious if this happens in the Pro version. Are there people who paid $10k for a tool (load ui pro) that can't handle sessions correctly?

As a note, checking for the JSESSIONID by hand doesn't work. Next thing I'm going to try is turning off session support and just using cookies directly.

Just verified that the same bug occurs in SoapUI Pro 4.5.1.

This is a simple testcase with 4 calls:

login/http
login/amf
search/amf
logout/http

There are two threads in the loadtest, with 1 run per thread.

This is what I see (from the Charles proxy). The second cookie is never used. I see from psiprobe that that other session is an anonymous session, hanging out on the server waiting to expire.

Request
POST /MY_APP/j_spring_security_check?j_username=testuser1&j_password=testpassword&submit=login HTTP/1.1
Response 1
Set-Cookie JSESSIONID=7E2EF24479D172EE9AE066D75B5F3AAC; Path=/MY_APP
Request 2
POST /MY_APP/j_spring_security_check?j_username=testuser2&j_password=testpassword&submit=login HTTP/1.1
Response 2
Set-Cookie JSESSIONID=C9D3A808721A6B9D3421737FD4EEE7FD; Path=/MY_APP
Request 3
Cookie JSESSIONID=C9D3A808721A6B9D3421737FD4EEE7FD
Request 4
Cookie JSESSIONID=C9D3A808721A6B9D3421737FD4EEE7FD
Request 5
Cookie JSESSIONID=C9D3A808721A6B9D3421737FD4EEE7FD
Request 6
Cookie JSESSIONID=C9D3A808721A6B9D3421737FD4EEE7FD
Request 7
GET /MY_APP/j_spring_security_logout HTTP/1.1
Cookie JSESSIONID=C9D3A808721A6B9D3421737FD4EEE7FD
Request 8
GET /MY_APP/j_spring_security_logout HTTP/1.1
Cookie JSESSIONID=C9D3A808721A6B9D3421737FD4EEE7FD

I noticed that the user-agent is:

User-Agent Apache-HttpClient/4.1.1 (java 1.5)

My local java is:

java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06-451-11M4406)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01-451, mixed mode)

Since sessions work fine when you run only test at a time, you can bypass the session bug by spawning multiple testrunners from a driver shell script and parameterizing in the script.

You won't get the fancy graphs, but you can log the data and use excel, etc to make graphs.

I haven't heard anything definitive, but apparently sessions aren't supported in load tests, even in the pro version.

Apparently the session is preserved in test cases now (4.5.2). Time to download it and see!

In 4.5.2, session cookies don't persist across different types of calls.

Call 1: HTTP POST
response: set-cookie
Call 2: AMF POST
request: no cookie present
Call 3: HTTP GET
request: cookie is present

The cookie should be set after call 1, but it's not present in call #2. It is present in call #3. This used to work in 3.5.1. HTTP session is checked, AMF session is not checked.

I have a testsuite that contains several login steps for different certificates..when run the test individually the test will pass sucessfully but when run in a suite the tests are failing.
The problem here is when second certficate login step executing, the first certificate is tryin to login and in response getting first certificate response.
How to expire the first login before execute the next login? or is there any other approach?