Re: Accessing StandardJMeterEngine.allThreads

On 13 August 2011 13:48, Andrey Pohilko <[email protected]> wrote:
> JMeter threads simulate not users, but browsers. And when application under
> test needs to have some parallel and synchronized activity, we need some
> inter-thread interaction.

JMeter threads are users, not browsers.

If regarded as a browser, then it is a browser with a single connection.

> Frequent example is AJAX, where requests goes in parallel, but need some
> synchronization. For example, while file upload goes in one thread, another
> must simulate progress bar updates.

That is an entirely separate issue.

If you treat JMeter threads as browser connections, how do you group
the connections for each browser?
And ensure that the groups don't interfere with each other?

> Furthermore, JMeter is very powerful and may be used to test non-Web
> systems, I myself tested MS RPC server with binary protocol, and had no
> solution for correct parallel keep-alive requests.
>
> Of course, I understand that synchronysing = locking. I hope that just
> requesting for JMeterVariable from another thread will be not so painful
> action. And users, of course, will be warned about locks.

There is already a function for property access.

JMeterVariables are quite complicated to process; I suspect the
overhead would be quite large.

> Giving access to allThreads opens thread manipulation for plugins, there may
> be more interesting ideas how to use this. Alas, I had to make tricks without
> it in Throughput Shaper...
>
> On Saturday 13 August 2011 16:36:43 sebb wrote:
>> On 13 August 2011 13:13, Andrey Pohilko <[email protected]> wrote:
>> > Hi all!
>> >
>> > JMeter users frequently ask for some inter-thread communications on
>> > JMeter forums.
>>
>> JMeter threads represent independent users; it should not be necessary
>> to pass data between them.
>>
>> JMeter 2.5 will support setUp threads, which solve many of the use
>> cases I have seen.
>>
>> > I have an idea of custom function that would give information from any
>> > thread for another thread. I think this will give wanted interaction.
>>
>> I'd like to see some use cases that truly require cross-thread
>> communication before considering this.
>> The danger is that the interaction between the threads will cause
>> unnecessary locking.
>>
>> > The problem implementing it is that only place where all JMeterThreads
>> > stored is StandardJMeterEngine.allThreads and I found no way to access
>> > that list.
>> >
>> > Field declaration from StandardJMeterEngine:
>> >        /** JMeterThread => its JVM thread */
>> >        private final Map<JMeterThread, Thread> allThreads;
>> >
>> >  So my questions are:
>> > 1. Is it possible to get access to that map in some read-only way (not to
>> > break anything...)?
>> > 2. If yes, how better do it: simple getter, or something more required?
>> > I'm ready to create and submit a patch to Bugzilla.
>> > 3. If the way is simple enough, could it be the part of JMeter 2.5
>> > release, because waiting another year for the next release is obviously
>> > undesirable?
>> >
>> > Sorry, if I'm asking for too much, but with my efforts, too, JMeter
>> > becoming more and more popular load testing tool.
>> >
>> > Thank you!
>> > --
>> > Andrey Pohilko
>> > JP@GC Maintainer
>> >
>> > ---------------------------------------------------------------------
>> > 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]
>
>