Forum Discussion

peterfrank's avatar
peterfrank
New Contributor
14 years ago

Cookie Handling SoapUI Runner

I believe I may have a series of bugs, and or mistakes on my part. We have a soapui 4.5 TestCase that works multithreaded within SoapUI because it appears that SoapUI is not respecting the "Maintain State" flag which is actually what I want to happen in loadui 2.0.1. That aside, in loadui it appears that cookies are being shared between threads, even though I would like cookies to be discarded between every request (ie not maintain state).

Below are two runs of a TestCase executed sequentially via loadui master but executed on a remote agent. (this behavior happens with multiple threads concurrently as well):


Run 1:
Request (no cookies initial run)
2012-05-15 16:50:59,863 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "POST /identity/auth_token_service HTTP/1.1[\r][\n]"
2012-05-15 16:50:59,864 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "Accept-Encoding: gzip,deflate[\r][\n]"
2012-05-15 16:50:59,864 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "Content-Type: text/xml;charset=UTF-8[\r][\n]"
2012-05-15 16:50:59,865 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "SOAPAction: "urn:ticketmaster:authtokenservice#generateAuthToken"[\r][\n]"
2012-05-15 16:50:59,865 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "Content-Length: 670[\r][\n]"
2012-05-15 16:50:59,865 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "Host: ws.shared.jetcap1.websys.tmcs[\r][\n]"
2012-05-15 16:50:59,865 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "Connection: Keep-Alive[\r][\n]"
2012-05-15 16:50:59,865 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "User-Agent: Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
2012-05-15 16:50:59,865 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "[\r][\n]"
2012-05-15 16:50:59,866 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:ticketmaster:authtokenservice">[\n]"
2012-05-15 16:50:59,866 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "   <soapenv:Header/>[\n]"
2012-05-15 16:50:59,867 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "   <soapenv:Body>[\n]"
2012-05-15 16:50:59,867 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "      <urn:generateAuthToken>[\n]"
2012-05-15 16:50:59,867 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "         <authTokenProtocolVersion xsi:type="xsd:string" xs:type="type:string" xmlns:xs="http://www.w3.org/2000/XMLSchema-instance">2.1.1</authTokenProtocolVersion>[\n]"
2012-05-15 16:50:59,867 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "         <uuid xsi:type="xsd:string" xs:type="type:string" xmlns:xs="http://www.w3.org/2000/XMLSchema-instance">captest_20120515045059288</uuid>[\n]"
2012-05-15 16:50:59,867 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "      </urn:generateAuthToken>[\n]"
2012-05-15 16:50:59,867 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "   </soapenv:Body>[\n]"
2012-05-15 16:50:59,867 DEBUG [org.apache.http.wire]-[executor-thread-8] >> "</soapenv:Envelope>"



Response (sets cookies)
2012-05-15 16:50:59,869 DEBUG [org.apache.http.wire]-[executor-thread-8] << "HTTP/1.1 200 OK[\r][\n]"
2012-05-15 16:50:59,871 DEBUG [org.apache.http.wire]-[executor-thread-8] << "Date: Tue, 15 May 2012 23:50:59 GMT[\r][\n]"
2012-05-15 16:50:59,871 DEBUG [org.apache.http.wire]-[executor-thread-8] << "Server: Apache[\r][\n]"
2012-05-15 16:50:59,871 DEBUG [org.apache.http.wire]-[executor-thread-8] << "Set-Cookie: SID=5Ce9oWkbRskjTF-0zDzoN7t2MQexUZxNCMH-e0iuCYp8TEje88mQhSNlabE32G7jI6A5En9Le-Ka75eB; path=/; domain=.shared.jetcap1.websys.tmcs[\r][\n]"
2012-05-15 16:50:59,871 DEBUG [org.apache.http.wire]-[executor-thread-8] << "Set-Cookie: BID=1HdnVNKxZiJqkt_Oi6k06OljvQiooc8lB3wiP6Q7ImTAvQcLt6u4Ee-sodWl_tmudraglA4o-ET4ZNTkJpmv; path=/; domain=.shared.jetcap1.websys.tmcs; expires=Fri, 01-Jan-2038 00:00:01 GMT[\r][\n]"
2012-05-15 16:50:59,871 DEBUG [org.apache.http.wire]-[executor-thread-8] << "X-UA-Compatible: chrome=1[\r][\n]"
2012-05-15 16:50:59,871 DEBUG [org.apache.http.wire]-[executor-thread-8] << "Vary: Accept-Encoding,User-Agent[\r][\n]"
2012-05-15 16:50:59,872 DEBUG [org.apache.http.wire]-[executor-thread-8] << "Content-Encoding: gzip[\r][\n]"
2012-05-15 16:50:59,872 DEBUG [org.apache.http.wire]-[executor-thread-8] << "X-Duration: D=2055[\r][\n]"
2012-05-15 16:50:59,872 DEBUG [org.apache.http.wire]-[executor-thread-8] << "Connection: close[\r][\n]"
2012-05-15 16:50:59,872 DEBUG [org.apache.http.wire]-[executor-thread-8] << "Transfer-Encoding: chunked[\r][\n]"
2012-05-15 16:50:59,872 DEBUG [org.apache.http.wire]-[executor-thread-8] << "Content-Type: text/xml; charset=utf-8[\r][\n]"



Run 2 (Same loadui agent session, in sequence, not concurrent, note the cookies from the completed first run of the TestCase is now reflected in the second run.  This also happens between concurrent runs):
Request(Same cookies that were set in Run1 response)
2012-05-15 16:51:29,967 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "POST /identity/auth_token_service HTTP/1.1[\r][\n]"
2012-05-15 16:51:29,967 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "Accept-Encoding: gzip,deflate[\r][\n]"
2012-05-15 16:51:29,968 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "Content-Type: text/xml;charset=UTF-8[\r][\n]"
2012-05-15 16:51:29,968 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "SOAPAction: "urn:ticketmaster:authtokenservice#generateAuthToken"[\r][\n]"
2012-05-15 16:51:29,968 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "Content-Length: 670[\r][\n]"
2012-05-15 16:51:29,968 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "Host: ws.shared.jetcap1.websys.tmcs[\r][\n]"
2012-05-15 16:51:29,968 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "Connection: Keep-Alive[\r][\n]"
2012-05-15 16:51:29,968 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "User-Agent: Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
2012-05-15 16:51:29,968 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "Cookie: BID=1HdnVNKxZiJqkt_Oi6k06OljvQiooc8lB3wiP6Q7ImTAvQcLt6u4Ee-sodWl_tmudraglA4o-ET4ZNTkJpmv; SID=5Ce9oWkbRskjTF-0zDzoN7t2MQexUZxNCMH-e0iuCYp8TEje88mQhSNlabE32G7jI6A5En9Le-Ka75eB[\r][\n]"
2012-05-15 16:51:29,968 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "Cookie2: $Version=1[\r][\n]"
2012-05-15 16:51:29,968 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "[\r][\n]"
2012-05-15 16:51:29,969 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:ticketmaster:authtokenservice">[\n]"
2012-05-15 16:51:29,969 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "   <soapenv:Header/>[\n]"
2012-05-15 16:51:29,969 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "   <soapenv:Body>[\n]"
2012-05-15 16:51:29,969 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "      <urn:generateAuthToken>[\n]"
2012-05-15 16:51:29,969 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "         <authTokenProtocolVersion xsi:type="xsd:string" xs:type="type:string" xmlns:xs="http://www.w3.org/2000/XMLSchema-instance">2.1.1</authTokenProtocolVersion>[\n]"
2012-05-15 16:51:29,969 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "         <uuid xsi:type="xsd:string" xs:type="type:string" xmlns:xs="http://www.w3.org/2000/XMLSchema-instance">captest_20120515045129904</uuid>[\n]"
2012-05-15 16:51:29,969 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "      </urn:generateAuthToken>[\n]"
2012-05-15 16:51:29,969 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "   </soapenv:Body>[\n]"
2012-05-15 16:51:29,969 DEBUG [org.apache.http.wire]-[executor-thread-5] >> "</soapenv:Envelope>"


Note that the cookie values are not set in the second run and the values are "holdovers" from the first run, yet they are on different threads (%t option in log4j). I can send my soapui xml file and more logs if it'll help. Thanks!

9 Replies

  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    Icon for Alumni rankAlumni
    14 years ago
    Hi!

    Thanks for the detailed description -- I'm investigating this.
    I'll get back to you within an hour.


    Regards

    Henrik
    loadUI developer
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    Icon for Alumni rankAlumni
    14 years ago
    Hi again!

    I have now verified a few things:


    • soapUI 4.5 has a bug [SOAPUI-3884] that makes it always maintain the session, regardless of settings. This is scheduled to be fixed in soapUI 4.5.1.

    • Since loadUI's soapUI Runner uses the soapUI engine, the bug affects loadUI as well.

    • The bug is not in loadUI 1.5 (soapUI 4.0).


    With that being said, this shouldn't be a hard bug to fix. I'll ask the soapUI team to have a look at it tomorrow -- hopefully they can fix it quite fast.


    Regards

    Henrik
  • peterfrank's avatar
    peterfrank
    New Contributor
    14 years ago
    The thing that concerned me most is that I assumed "Maintain Session" was on a "thread" and not on a "client" (ie loadui agent would be a single client but simulating many clients on separate threads). What I was seeing with many threads executing the same TestCase on loadui the session was passed between threads which never seems right. If a session is maintained for a client thread of execution would be fine (provided it can be turned off as well) but maintaining a the same HttpState object (I don't know HttpClient 4.0 but for 3.x this was the state object) between threads seems wrong regardless of the application respecting the "maintain session" configuration. Am i wrong about my understanding of the bug?
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    Icon for Alumni rankAlumni
    14 years ago
    Hi Peter!

    You're completely right. Sessions should never be shared between virtual users ("threads"). LoadUI 1.5, which doesn't suffer from this bug, does not share sessions in such way &mdash; and neither will loadUI 2.0.2.

    Regards
    Henrik
  • roopam's avatar
    roopam
    14 years ago
    Hi,
    I am facing an issue that seems relevant to this thread.
    My test case is using a data source, using which I am logging in multiple users. After login the user does “some action” and then logs out.
    The load test of this test case in SOAPui 4.0.0 was working as expected without any problem.
    We recently upgraded to 4.5.0 and since then the test case is failing.

    The web application being tested requires http session to be maintained and this option is checked. The web application being tested is https.

    Observed :
    Say datasource has 10 user credentials.
    In load test I am using 10 threads and doing one run per thread.
    On execution, the login for all users is successful but the “some action” and logout is done by only one user (the user that logged in last)
    Seems like only one session/connection is maintained between SOAPui and my application.

    Is this in any way related to the issue discussed in this thread??
    If no then sorry for spamming here but I still need help figuring this one out.
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    Icon for Alumni rankAlumni
    14 years ago
    roopam wrote:
    Hi,
    I am facing an issue that seems relevant to this thread.
    My test case is using a data source, using which I am logging in multiple users. After login the user does “some action” and then logs out.
    The load test of this test case in SOAPui 4.0.0 was working as expected without any problem.
    We recently upgraded to 4.5.0 and since then the test case is failing.

    The web application being tested requires http session to be maintained and this option is checked. The web application being tested is https.

    Observed :
    Say datasource has 10 user credentials.
    In load test I am using 10 threads and doing one run per thread.
    On execution, the login for all users is successful but the “some action” and logout is done by only one user (the user that logged in last)
    Seems like only one session/connection is maintained between SOAPui and my application.

    Is this in any way related to the issue discussed in this thread??
    If no then sorry for spamming here but I still need help figuring this one out.

    Yes, it's probably the same issue. Try the latest nightly build of soapUI Pro -- it should be fixed there.

    /Henrik
  • rumcajz's avatar
    rumcajz
    New Contributor
    13 years ago
    Are you absolutely sure this is fixed in SoapUI 4.5.1? Because I am using it and I am facing a similar issue.

    I have a script with "Maintain HTTP session" checked.
    The script first gets a login from the database (based on a sequence that is incremented with each request), then it does an HTTPS login and next goes on with some actions.

    I logged to a file the logins and passwords the login request gets from the database. They're different for each thread. Unfortunately when I run a load test with 3 such threads all the actions happen for one login, as if there was a bug in SoapUI 4.5.1 that causes that threads share the HTTP session!

    This makes it SoapUI useless for functional load testing...

    Do you have any version of SoapUI where this is fixed? If not, when will it be fixed?

    Regards,
    Radek
  • rumcajz's avatar
    rumcajz
    New Contributor
    13 years ago
    Just tried SoapUI Pro 4.5.1 trial and it does not fix the issue I am having. Still, the threads seem to be sharing the session.

    I would run this through LoadUI 2.1.0 to see if this helps, but it does not work with HTTPS, which I need to use.

    What can we do about it?

    Please help.

    Regards,
    Radek