I'm using Jetty and it assigns a new jsession every time one is not passed
to it. That works very well. If the cookie manager is put into the test
plan, the jsession id is passed to jetty and it does not assign a new one.
That is evident by my testing.
However, it should allocate a new cookie every time the Cookie Manager
parent controller loops.
k, that is my understanding as well.
What I was really hoping for was a new session id for each thread at
the
restart of the loop. That didn't seem to happen even though the clear
cookies flag was set.
In that case, either there is a JMeter bug (AFAIK, 2.3.2 Cookie
Manager is working OK), or the server must be resending the same
cookie to JMeter.
I'll vote JMeter problem although it may not be a bug per say. The fact
that all sessions that don't have a jsession id are assigned one and that
one is always sent by JMeter even with the clear cookies box ticked suggests
I've not seen that - are you sure cookies are being sent after being cleared?
yes, the server is reporting on the jsession as you can see in the
output. If the cookie manager is deleted from the test plan, a new
jsession is assigned on every simple sample.
that maybe cookies are cleared by jsession isn't. If that doesn't happen,
jmeter, tomcat and like will use the same session unless the application
over-rides with it's own cookies.
When looking for why that was happening I noted that
only one thread was being worked which made my test even worse.
I assume you are referring to a server thread.
No, the JMeter threading.
That's probably due to the Throughput Controller.
The output you are looking at was produced before I went to the *weird*
configuration and before I started using the throughput controller.
From the output you can see that requests
received by the server were almost completely dominated by a single
jsession id. This implies that one thread in JMeter was responsible for most
of the load on the server. If there were a way to clear the jsession id,
that wouldn't matter. However.....
Which can well be the case if that's what the Throughput Controller
has been told to do ...
ok, but just to be clear, this threading question was observed prior to
my using the through put controller. I only started going *weird* in an
attempt to work around the problem.
I think what I need to do next is post a test servlet along with a test
plan. The application that I'm currently using is a wee bit too big to post.
Regards,
Kirk
Here is the output from my test servlet. The thread
group
is configured for 3 threads The cookie manager is set to clear
cookies
at
the end of each iteration.
15nhcqlwugmkh
npli36fysau0
1nmwz0414pt0d
npli36fysau0
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
15nhcqlwugmkh
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
...
Is this expected behavior?
Difficult to say without knowing how the session ids are allocated and
how many samplers there are in the thread.
You might find it helpful to turn on debugging for the Cookie Manager
(e.g. select it and use Help/Enable debug).
The View Results Tree Listener can be used to show the cookies; you
can see noew ones are being sent by the server.
Server cookies are also stored as variables, so you could save those
in the JTL file:
http://jakarta.apache.org/jmeter/usermanual/listeners.html#sample_variables
Thanks,
Kirk
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
