jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dillenseger <>
Subject Re: Sharing objects between samplers ?
Date Wed, 19 Feb 2003 09:09:47 GMT
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:
For additional commands, e-mail:

View raw message