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 simplychoose 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]
