Might also be worth trying the Apache HTTPClient Sampler instead of the default.
You could also try logging the extracted session ids using a Java Sampler or one of the __log()/__logn() functions. If this does not reveal the problem, then we would need a Bugzilla report with attachments of the testplan (obliterate any private details first) and jmeter.log. S. On 14/10/05, Noam Paz <[EMAIL PROTECTED]> wrote: > > > > > > Hi Peter, > I am using Tomcat (4.1.18.0). I'm not really sure what you mean by your > second question, but AFAIK it is Tomcat, and not the application server, > which creates the session ids. > You wrote: > >> jmeter will use what ever session id the server sends > My questions are: > 1. Can it be that JMeter gets from the server two session ids, say session id > 103 adressed for thread 3 and session id 104 addressed for thread 4, but > delievers both thread 3 and thread 4 with session id 103? > 2. How comes that threads 3 and 4, both receiving session id 103 from the > login request, pass in the next request a different session id (in the > example below 500 and 600)? > Thanks for your help! > > Best regards > > Noam Paz > > > > > > Peter Lin <[EMAIL PROTECTED]> > > 14.10.2005 12:58 > > > > > > > > > > > > To > > > > > > JMeter Users List <[email protected]> > > > > > > > > > > > > > cc > > > Please respond to > > > "JMeter Users List" <[email protected]> > > > > > > > > > > Subject > > > > > > Re: Another problem with the cookie manager?? > > > > > > > > > > > jmeter will use what ever session id the server sends. so if the server > really is sending back the duplicate session id, jmeter doesn't bother to > check the session id is unique. which server are you using and is it using > the server provided session id? > > peter > > > On 10/14/05, Noam Paz <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Hello, > > perhaps this is a problem caused by the cookie manager? > > > > I encounter a rather strange behaviour involving JMeter (2.0.2 on JKD > > 1.4.2_05) and Tomcat (4.1.18.0 <http://4.1.18.0>). > > *Sometimes* in my load test the session is being invalidated after the > > login. > > > > With low load (<= 10 Threads) the tests run without problems. > > With higher loads all threads are successful with the first request > > (login) but some of them (about 15%) fail in the second request because of > > an invalid session. > > > > Investigating the requests and the responses I have concluded that > > 1. In threads that perform timely adjucent logins exactly the same > > sessionids are received. > > 2. When these threads perform the second request, they send another > > sessionid. These new sessionids differ from each other and do not belong to > > any earlier thread. > > > > Example (simplified): > > Thread sessionid in Login/Response Sessionid in CustomerSelect/request > > 1 101 101 (OK) > > 2 102 102 (OK) > > 3 103 500 (not OK) > > 4 103 (same as in #3) 600 (not OK) > > > > My questions: > > - What might be the cause of the identical sessionids for the different > > threads? > > Is it a know problem in either JMeter or Tomcat? > > - Why does JMeter send a fake sessionid? > > > > One idea was that the concurrent logins might count as one login trial > > because of the KeepAlive flag. > > I have turned the KeepAlive flag from the login request off, but this did > > not help. > > > > Does anybody have further ideas? > > > > Thanks in advance! > > > > Noam Paz > > > > P.S. > > Of course I use the cookie manager in my testplan and do not manipulate > > the sessionid in the testplan. > > > > Best regards / Viele Gr��e > > > > Noam Paz > > > > Deutsche Bank AG > > GTO CIO PCB IT/O > > Sales & Advisory IT > > Brokerage & Advisory > > Financial Planning > > > > Alfred Herrhausen Allee 10a > > D-65760 Eschborn > > > > Tel: +49-69-910-69308 > > Fax: +49-69-910-68425 > > Mailto:[EMAIL PROTECTED] > > http://is.ds.gt.pcam.intranet.db.com > > > > > > > > -- > > > > Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte > > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail > > irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und > > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte > > Weitergabe dieser Mail ist nicht gestattet. > > > > This e-mail may contain confidential and/or privileged information. If you > > are not the intended recipient (or have received this e-mail in error) > > please notify the sender immediately and destroy this e-mail. Any > > unauthorized copying, disclosure or distribution of the material in this > > e-mail is strictly forbidden. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > > Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail > irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte > Weitergabe dieser Mail ist nicht gestattet. > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) please > notify the sender immediately and destroy this e-mail. Any unauthorized > copying, disclosure or distribution of the material in this e-mail is > strictly forbidden. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
