jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: setup & teardown thread group concurrency
Date Fri, 02 Nov 2012 02:27:03 GMT
On 2 November 2012 01:21, Stott, Charlie <> wrote:
> Hi,
> Thanks for the reply.
>> > I am finding that the setup thread appears to run concurrently with all the
other thread groups.
>> What makes you think that?
> I have a pre-processor which stores a value in a property in the setup thread group.
> Samples that are processed in setup thread group respect the value of the property, but
samples processed in other thread groups have not got it set yet, although it often becomes
set during the processing of the group.

For a property, that's not possible.

> I understand scope of properties is global.  I also notice that some setup samples process
after samples from non-setup thread group.

That's not possible.

> I find the behaviour is different depending if I set the consecutive setting in the test
> Are properties asynchronous?

No, neither are variables.

> That might also explain the behaviour?   I think I need to understand scope and function
much better with regard to properties and variables.
> I understand that variables are local to thread group, but is this also true in the case
of setup thread (I assumed it was due to concurrency).

The setup group threads behave exactly like the main thread group threads.

> On completion of the setup thread group, will all variables changes be discarded?

Yes, because they are local to each thread (not the thread group)

>  I think I might have assumed that other thread groups threads were actually started
after completion of setup threads, but perhaps they are all started early, then delayed until
setup is complete?

No, as I already wrote, the setup threads all complete before the main
thread group(s) start.

> I will try to provide a simple test plan snippet to check my expectations with the group.

That would be best, as the behaviour you describe is not possible (if
I'm understanding it correctly).

>> > Is this proper behaviour?
>> No.
> Thanks particularly for confirming this.  It means I don't mind persevering to work out
what I am doing wrong.
> Cheers,
> Charlie
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message