Re: Accessing StandardJMeterEngine.allThreads

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 <[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]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]