You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Jens Müller <je...@hotmail.com> on 2011/01/20 17:00:40 UTC

"On error goto" behavior

Hi,
 
I would like to have a test that logs in, does some actions for a specified runtime. If during the runtime an assertion fails (session expired), the virtual users should go back and login again.
 
How can I achieve this in the nicest way?
 
I could use the following, but I don't know how to set a variable if the assertion fails for example
runtime controller
  if controller (if no session)
    login
    beanshell set session=true
  request1
    assertion1
  request2
    assertion2
  request3
 ...
 
I probably (?) would then need to use bean shell assertions that set the session variable to false if they find out that it has expired. In the next loop of the runtime controller the test would then login again.
 
I don't like this solution as I cannot make use of the exisiting JMeter assertions (response assertion) but would need to code it myself in all the beanshell assertions, only to be able to set a variable. Maybe I could access the assertion results form a post processor - somewhat better except it fills my tree with more and more elements.
 
Another problem with this approach is that I use module controllers to re use elements like login in a way that login must not be child element of my test case's runtime controller...
 
In fact what I would need is a "On error goto x" and "resume" construct which would jump to login in case of this specific error. I guess this is not foreseen, right?
 
Thank you,
Jens 		 	   		  
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: "On error goto" behavior

Posted by Deepak Shetty <sh...@gmail.com>.
out of curiosity why does the session expire? you wont be giving that large
think times and the next request would reset the clock?



On Thu, Jan 20, 2011 at 4:53 PM, Deepak Shetty <sh...@gmail.com> wrote:

> hi
> for any error or just the specfic error that you are looking for?
> If specific error that you seem to have mentioned then you could try adding
> a BeanShell listener(scoped to the if statement) to set the variable.
>
>
> http://jakarta.apache.org/jmeter/api/org/apache/jmeter/samplers/SampleResult.html#getAssertionResults()<http://jakarta.apache.org/jmeter/api/org/apache/jmeter/samplers/SampleResult.html#getAssertionResults%28%29>
> The listener could check which assertion failed and set the variable
> accordingly. You could also have an if controller that checks the value of
> this variable and evaluates this for every child so that the other requests
> dont get executed . But im not sure whether this all happens synchronously
> (calling the listener after the sampler and before calling the next sampler)
> which would be needed for this to work. give it a try and see.
> Note that your assertions remain the same you dont have to change what
> asserter you are using
>
>
> regards
> deepak
>
>
>
> On Thu, Jan 20, 2011 at 8:00 AM, Jens Müller <je...@hotmail.com> wrote:
>
>>
>> Hi,
>>
>> I would like to have a test that logs in, does some actions for a
>> specified runtime. If during the runtime an assertion fails (session
>> expired), the virtual users should go back and login again.
>>
>> How can I achieve this in the nicest way?
>>
>> I could use the following, but I don't know how to set a variable if the
>> assertion fails for example
>> runtime controller
>>  if controller (if no session)
>>    login
>>    beanshell set session=true
>>  request1
>>    assertion1
>>  request2
>>    assertion2
>>  request3
>>  ...
>>
>> I probably (?) would then need to use bean shell assertions that set the
>> session variable to false if they find out that it has expired. In the next
>> loop of the runtime controller the test would then login again.
>>
>> I don't like this solution as I cannot make use of the exisiting JMeter
>> assertions (response assertion) but would need to code it myself in all the
>> beanshell assertions, only to be able to set a variable. Maybe I could
>> access the assertion results form a post processor - somewhat better except
>> it fills my tree with more and more elements.
>>
>> Another problem with this approach is that I use module controllers to re
>> use elements like login in a way that login must not be child element of my
>> test case's runtime controller...
>>
>> In fact what I would need is a "On error goto x" and "resume" construct
>> which would jump to login in case of this specific error. I guess this is
>> not foreseen, right?
>>
>> Thank you,
>> Jens
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>

Re: "On error goto" behavior

Posted by Deepak Shetty <sh...@gmail.com>.
assertions run after post processors I think

On Fri, Jan 21, 2011 at 12:00 AM, Felix Frank <ff...@mpexnet.de> wrote:

> >> If specific error that you seem to have mentioned then you could try
> adding
> >> a BeanShell listener(scoped to the if statement) to set the variable.
> >>
> >>
> http://jakarta.apache.org/jmeter/api/org/apache/jmeter/samplers/SampleResult.html#getAssertionResults()<http://jakarta.apache.org/jmeter/api/org/apache/jmeter/samplers/SampleResult.html#getAssertionResults%28%29>
> >> The listener could check which assertion failed and set the variable
> >> accordingly.
> >
> > Ok, but isn't it the case that listeners are only executed on the JMeter
> controller in distributed mode and not on the agents? Therefore the variable
> that would be set would not be available on the agent executing the test.
>
> I believe so, yes.
>
> Maybe a BeanshellPostProcessor will do you more good then?
>
> Cheers,
> Felix
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

Re: "On error goto" behavior

Posted by sebb <se...@gmail.com>.
On 21 January 2011 08:00, Felix Frank <ff...@mpexnet.de> wrote:
>>> If specific error that you seem to have mentioned then you could try
> adding
>>> a BeanShell listener(scoped to the if statement) to set the variable.
>>>
>>> http://jakarta.apache.org/jmeter/api/org/apache/jmeter/samplers/SampleResult.html#getAssertionResults()
>>> The listener could check which assertion failed and set the variable
>>> accordingly.
>>
>> Ok, but isn't it the case that listeners are only executed on the JMeter controller in distributed mode and not on the agents? Therefore the variable that would be set would not be available on the agent executing the test.
>
> I believe so, yes.
>
> Maybe a BeanshellPostProcessor will do you more good then?

Note that the status of any sample is saved in

JMeterThread.last_sample_ok - whether or not the last sample was OK -
true/false

See:

http://jakarta.apache.org/jmeter/usermanual/functions.html#predefinedvars

This can be used in an If Controller to skip subsequent parts of a test.

> Cheers,
> Felix
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: "On error goto" behavior

Posted by Felix Frank <ff...@mpexnet.de>.
>> If specific error that you seem to have mentioned then you could try
adding
>> a BeanShell listener(scoped to the if statement) to set the variable.
>>
>> http://jakarta.apache.org/jmeter/api/org/apache/jmeter/samplers/SampleResult.html#getAssertionResults()
>> The listener could check which assertion failed and set the variable
>> accordingly. 
> 
> Ok, but isn't it the case that listeners are only executed on the JMeter controller in distributed mode and not on the agents? Therefore the variable that would be set would not be available on the agent executing the test.

I believe so, yes.

Maybe a BeanshellPostProcessor will do you more good then?

Cheers,
Felix

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: "On error goto" behavior

Posted by Deepak Shetty <sh...@gmail.com>.
Ok i tried this
ThreadGroup
+Loop=10
+DebugSampler (with pre processor to initialise sessionExpired = false)
+IfController(Condition = '${sessionExpired}' != 'true' , Evaluate for all
Children=true)
++dummy Beanshell sampler0
+++Some Assertion that always fails
++dummy Beanshell sampler1
++dummy Beanshell sampler 2 (pretends expiry)
++dummy Beanshell sampler 3 (pretends expiry)
++Response Text Assertion for expiry check(assuming you can use the same one
for all samplers otherwise this could be under every sampler)
++Beanshell Assertion (to set variable , pseudo code below, MUST be after
the Expiry Check assertion above)

seems to work as you want.

regards
deepak


import org.apache.jmeter.assertions.AssertionResult;
if(SampleResult != null) {
   AssertionResult[]  results = SampleResult.getAssertionResults();
   for(int i=0;results!= null && i<results.length;i++){
      AssertionResult result = results[i];
       if("ExpiryCheck".equalsIgnoreCase(result.getName()) &&
(result.isError() || result.isFailure())){
            vars.put("sessionExpired","true"); //variable is reset at start
of loop in the test
       }
   }
}
Failure=false;
failureMessage="";





On Fri, Jan 21, 2011 at 8:22 AM, Deepak Shetty <sh...@gmail.com> wrote:

> >Ok, but isn't it the case that listeners are only executed on the JMeter
> controller in distributed mode and not on the agents?
> It works for me :), since i always use multiple instances rather than
> distributed mode .
> Perhaps you could try adding a Beanshell assertion that always executes
> after the other assertions . JMeterThread.last_sample_ok would have worked
> if any error needed this behavior.
>
>
>
>
> On Thu, Jan 20, 2011 at 11:43 PM, Jens Müller <je...@hotmail.com> wrote:
>
>>
>> Hi and thank you.
>>
>> > for any error or just the specfic error that you are looking for?
>>
>> This behavior only for the specific error.
>>
>> > If specific error that you seem to have mentioned then you could try
>> adding
>> > a BeanShell listener(scoped to the if statement) to set the variable.
>> >
>> >
>> http://jakarta.apache.org/jmeter/api/org/apache/jmeter/samplers/SampleResult.html#getAssertionResults()<http://jakarta.apache.org/jmeter/api/org/apache/jmeter/samplers/SampleResult.html#getAssertionResults%28%29>
>> > The listener could check which assertion failed and set the variable
>> > accordingly.
>>
>> Ok, but isn't it the case that listeners are only executed on the JMeter
>> controller in distributed mode and not on the agents? Therefore the variable
>> that would be set would not be available on the agent executing the test.
>>
>> > You could also have an if controller that checks the value of
>> > this variable and evaluates this for every child so that the other
>> requests
>> > dont get executed.
>>
>> Right.
>>
>> > But im not sure whether this all happens synchronously
>> > (calling the listener after the sampler and before calling the next
>> sampler)
>> > which would be needed for this to work.
>>
>> See my comment above, I don't think this is a good solution.
>>
>> > out of curiosity why does the session expire? you wont be giving that
>> large
>> > think times and the next request would reset the clock?
>>
>> On easy example: The server is restarted during a long load test run. All
>> subsequent requests would be meaningless as the session is lost.
>> Jens
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>

Re: "On error goto" behavior

Posted by Deepak Shetty <sh...@gmail.com>.
>Ok, but isn't it the case that listeners are only executed on the JMeter
controller in distributed mode and not on the agents?
It works for me :), since i always use multiple instances rather than
distributed mode .
Perhaps you could try adding a Beanshell assertion that always executes
after the other assertions . JMeterThread.last_sample_ok would have worked
if any error needed this behavior.



On Thu, Jan 20, 2011 at 11:43 PM, Jens Müller <je...@hotmail.com> wrote:

>
> Hi and thank you.
>
> > for any error or just the specfic error that you are looking for?
>
> This behavior only for the specific error.
>
> > If specific error that you seem to have mentioned then you could try
> adding
> > a BeanShell listener(scoped to the if statement) to set the variable.
> >
> >
> http://jakarta.apache.org/jmeter/api/org/apache/jmeter/samplers/SampleResult.html#getAssertionResults()<http://jakarta.apache.org/jmeter/api/org/apache/jmeter/samplers/SampleResult.html#getAssertionResults%28%29>
> > The listener could check which assertion failed and set the variable
> > accordingly.
>
> Ok, but isn't it the case that listeners are only executed on the JMeter
> controller in distributed mode and not on the agents? Therefore the variable
> that would be set would not be available on the agent executing the test.
>
> > You could also have an if controller that checks the value of
> > this variable and evaluates this for every child so that the other
> requests
> > dont get executed.
>
> Right.
>
> > But im not sure whether this all happens synchronously
> > (calling the listener after the sampler and before calling the next
> sampler)
> > which would be needed for this to work.
>
> See my comment above, I don't think this is a good solution.
>
> > out of curiosity why does the session expire? you wont be giving that
> large
> > think times and the next request would reset the clock?
>
> On easy example: The server is restarted during a long load test run. All
> subsequent requests would be meaningless as the session is lost.
> Jens
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

RE: "On error goto" behavior

Posted by Jens Müller <je...@hotmail.com>.
Hi and thank you.

> for any error or just the specfic error that you are looking for?

This behavior only for the specific error.

> If specific error that you seem to have mentioned then you could try adding
> a BeanShell listener(scoped to the if statement) to set the variable.
>
> http://jakarta.apache.org/jmeter/api/org/apache/jmeter/samplers/SampleResult.html#getAssertionResults()
> The listener could check which assertion failed and set the variable
> accordingly. 

Ok, but isn't it the case that listeners are only executed on the JMeter controller in distributed mode and not on the agents? Therefore the variable that would be set would not be available on the agent executing the test.

> You could also have an if controller that checks the value of
> this variable and evaluates this for every child so that the other requests
> dont get executed.

Right.

> But im not sure whether this all happens synchronously
> (calling the listener after the sampler and before calling the next sampler)
> which would be needed for this to work. 

See my comment above, I don't think this is a good solution.

> out of curiosity why does the session expire? you wont be giving that large
> think times and the next request would reset the clock?

On easy example: The server is restarted during a long load test run. All subsequent requests would be meaningless as the session is lost.
Jens
 		 	   		  
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: "On error goto" behavior

Posted by Deepak Shetty <sh...@gmail.com>.
hi
for any error or just the specfic error that you are looking for?
If specific error that you seem to have mentioned then you could try adding
a BeanShell listener(scoped to the if statement) to set the variable.

http://jakarta.apache.org/jmeter/api/org/apache/jmeter/samplers/SampleResult.html#getAssertionResults()
The listener could check which assertion failed and set the variable
accordingly. You could also have an if controller that checks the value of
this variable and evaluates this for every child so that the other requests
dont get executed . But im not sure whether this all happens synchronously
(calling the listener after the sampler and before calling the next sampler)
which would be needed for this to work. give it a try and see.
Note that your assertions remain the same you dont have to change what
asserter you are using


regards
deepak


On Thu, Jan 20, 2011 at 8:00 AM, Jens Müller <je...@hotmail.com> wrote:

>
> Hi,
>
> I would like to have a test that logs in, does some actions for a specified
> runtime. If during the runtime an assertion fails (session expired), the
> virtual users should go back and login again.
>
> How can I achieve this in the nicest way?
>
> I could use the following, but I don't know how to set a variable if the
> assertion fails for example
> runtime controller
>  if controller (if no session)
>    login
>    beanshell set session=true
>  request1
>    assertion1
>  request2
>    assertion2
>  request3
>  ...
>
> I probably (?) would then need to use bean shell assertions that set the
> session variable to false if they find out that it has expired. In the next
> loop of the runtime controller the test would then login again.
>
> I don't like this solution as I cannot make use of the exisiting JMeter
> assertions (response assertion) but would need to code it myself in all the
> beanshell assertions, only to be able to set a variable. Maybe I could
> access the assertion results form a post processor - somewhat better except
> it fills my tree with more and more elements.
>
> Another problem with this approach is that I use module controllers to re
> use elements like login in a way that login must not be child element of my
> test case's runtime controller...
>
> In fact what I would need is a "On error goto x" and "resume" construct
> which would jump to login in case of this specific error. I guess this is
> not foreseen, right?
>
> Thank you,
> Jens
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>