Hello,
I'm glad to tell you the problem we had has nothing to do with JMeter.
It was the application changing the cookies in a JSP. In the next action the application was expecting the nonexistent cookie... :-(
Thanks, Sebb and Peter, for your valuable hints!
Best regards
Noam Paz
sebb <se...@gmail.com>
14.10.2005 15:00 To
JMeter Users List <jm...@jakarta.apache.org>
cc
Please respond to
"JMeter Users List" <jm...@jakarta.apache.org> Subject
Re: Another problem with the cookie manager??
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 <no...@db.com> 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 <wo...@gmail.com>
>
> 14.10.2005 12:58 To
> JMeter Users List <jm...@jakarta.apache.org>
> cc
> Please respond to
> "JMeter Users List" <jm...@jakarta.apache.org> 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 <no...@db.com> 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:noam.paz@db.com
> > 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: jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >
> >
>
>
>
> --
>
> 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: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
--
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.