You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jakarta.apache.org by Andrey Pohilko <ap...@apc.kg> on 2011/08/13 14:13:08 UTC
Accessing StandardJMeterEngine.allThreads
Hi all!
JMeter users frequently ask for some inter-thread communications on JMeter
forums. I have an idea of custom function that would give information from any
thread for another thread. I think this will give wanted interaction.
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: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: Accessing StandardJMeterEngine.allThreads
Posted by Andrey Pohilko <ap...@apc.kg>.
Well, I'd group connections like using properties - defining some criteria like
__threadNum-based...
Ok, I got your position.
Thank you for explaining.
On Saturday 13 August 2011 17:31:56 sebb wrote:
> On 13 August 2011 13:48, Andrey Pohilko <ap...@apc.kg> 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 <ap...@apc.kg> 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: dev-unsubscribe@jakarta.apache.org
> >> > For additional commands, e-mail: dev-help@jakarta.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: Accessing StandardJMeterEngine.allThreads
Posted by sebb <se...@gmail.com>.
On 13 August 2011 13:48, Andrey Pohilko <ap...@apc.kg> 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 <ap...@apc.kg> 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: dev-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: Accessing StandardJMeterEngine.allThreads
Posted by Andrey Pohilko <ap...@apc.kg>.
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.
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.
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.
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 <ap...@apc.kg> 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: dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: Accessing StandardJMeterEngine.allThreads
Posted by sebb <se...@gmail.com>.
On 13 August 2011 13:13, Andrey Pohilko <ap...@apc.kg> 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: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org