On 05/12/2008, kirk <[EMAIL PROTECTED]> wrote: > sebb wrote: > > > On 05/12/2008, kirk <[EMAIL PROTECTED]> wrote: > > > > > > > Hi sebb, > > > > > > These are actualy jsessionid's. For the test I used 2 samplers in the > > > thread with only 3 threads. I was looking for the information in the > tree > > > listener and it correlated with what the server was saying. > > > > > > > > > > > > > I don't know for certain how jsession ids are passed from client to > > server. Assuming that this is done via cookies, then JMeter will only > > send the cookie if there is a Cookie Manager and the cookie matches > > the domain. Cookies are stored by the Cookie Manager for the local > > thread only, so each thread can have the same cookie name with > > different values. > > > > If "Clear Cookies each iteration" is selected, then cookies will be > > cleared at the start of each iteration of the parent container - > > usually the Thread Group. > > > > The cookie is intially stored on receipt of a Set-Cookie: header. > > > > The server is free to provide whatever cookies it wishes. It may > > generate a new cookie each time it sees a request without a cookie > > (e.g. that is what Google seems to do), or it may require a login. > > > > > 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. > > > > > > > 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? > 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. > 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 ... > > > > > > > Not having a > > > cookie manager cases the server to react as expected in that there is a > new > > > jsession assigned to each sampler request. I'm using the latest release. > > > > > > > > > > Do you mean 2.3.2? > > > > > yes, and I tried it in a couple of previous versions also. The behavior was > the same. The Throughput Controller has not changed in a while, though the documentation has been updated. > 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]
