I think using JMeterVariables to share an object between multiple custom sampler classes only works if the samplers execute ONCE per test plan.
AbstractSampler implements PerSampleClonable which means that the sampler object is cloned each iteration. If a custom sampler class implements ThreadListener the instance that is registered with JMeterThread when it starts up will be different from each cloned instance that is used each iteration, thus making it impossible to access the JMeterVariables after the first iteration in the test plan. Does anyone know why it is necessary to clone sampler objects each iteration? > -----Original Message----- > From: Bruno Dillenseger > [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 19, 2003 3:10 AM > To: JMeter Users List > Subject: Re: Sharing objects between samplers ? > > > Mike Stover a �crit: > > >What you're doing is similar to what the JMeterVariables > object provides you - a > >place to store values by thread. By implementing the > ThreadListener interface, > >you are given access to the JMeterVariables. Currently, it > only allows the storage > >of string variables, but there's no reason you could simply > modify it to store objects > >as well. > > > Thanks for these guidelines. > > >Regarding samplers that can do more than one thing - I'd > like to expand the > >sampler interface to allow one sampler to return multiple > SampleResults (via a > >callback interface) and do mutliple things. I'd then like > to make a scripted Sampler > >that allowed one to write some J/Python code into JMeter's > gui that would then be > >run as the Sampler's sample() method. Is this kind of what > you mean by allowing a > >single sampler to do more? > > > > > Scripting is an important feature (e.g. J/Python code in Grinder or > TestMaker). Jmeter's new Javascript extension brought by Thad Smith > seems very interesting. > What I mean is: I would feel it convenient to create a kind > of "virtual > user" class holding several sampling methods and a "virtual > user state". > From the GUI, instead of choosing a Java sampler class, I > would simply > choose a sampling method of my "virtual user". Or, to simplify, there > could be a single sampling method like it is now, and I would give > arguments in the GUI that allows my code to switch to the > right sampling > method; this is what I actually do today, using a static hashtable > variable to store the states of my "virtual users". > > It seems that Jmeter has another approach/granularity using > Samplers and > JMeterVariables instead of "virtual users". Do you know the > reason for > such a design choice? > > About my deadlocks: is it allowed/safe to do synchronization > (synchronized/wait/notify) of Jmeter's threads in samplers? > > Thanks for your support, > -- Bruno. > > >On 17 Feb 2003 at 9:42, Bruno Dillenseger wrote: > > > > > >>I don't know if what I do is the cleanest way (it might be > actually a dirty way), but it is straightforward: > >>- the connect sampler fills a static hashtable object with > its current thread as key and your custom server reference > object as value; > >>- the disconnect sampler retrieves the reference from the > hashtable, using its current thread as key. > >> > >>I even do some synchronization on this thread object > (wait()/notify()) and I get deadlocks in a couple of threads > from time to time, without knowing if it is caused by a bug > in my code, or if it results from a conflict between by code > and internal synchronization of Jmeter's thread management > >> > >> > >> From my point of view, I don't feel it convenient to > proceed this way. I would feel it more convenient to have a > single sampler object with its own state, performing a > variety of operations during the test plan. > >> > >>If a Jmeter developper reads this, probably s/he can > comment on my workaround? > >> > >> > > > > --------------------------------------------------------------------- > 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]
