I wasn't very clear on what you meant by virtual users and virtual user state. JMeter is the way it is mostly out of a desire to provide non-programmers with a full-featured testing tool. Scripting is desirable, but being gui-driven and not requiring programming experience is just as important to me. I'm not trying to recreate TestMaker.
-Mike On 19 Feb 2003 at 10:09, Bruno Dillenseger wrote: > 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] > -- 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]
