You just have to implement the clone() method correctly. Samplers are cloned because their data is often modified during test runs.
-Mike On 20 Feb 2003 at 11:25, Grommes, Ben wrote: > 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] > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
