>It's because the UDVs are processed before the test is started - they define >the initial variables that are copied to all >threads.
Why do we copy values to all threads that are defined to have context only within a thread? We can't use UDV to update it again 'across all threads' since its only processed at startup.. We can't do anything to it in one thread to modify its value in another thread. So why do we bother copying it to all threads? If I want something to be across all threads, that's why we use properties. I can define a property 'across all threads' and then modify a copy of it locally as a variable. That would be the structured programming way to do it. I don't understand why jmeter insists on bastardizing how variables are used compared to every other language out there. >The variables are intended for items that don't change during a test run, >but which may change between runs. Variables should be usable as they are in every language - which is to hold values and allow you to reuse those values and update them. All I'm trying to do is use variables as holder values so the code is more managable. If you are reusing the same string over and over - it should be a variable so if you change it, you don't have to update every instance of it in the project. I simply have a logdir variable that is used in all my listeners, so I don't have to put static values in every configuration that if things change, I must change it in every listener. >User Parameters are per thread. If you use values that don't change >during a run, then these will be the same across the thread group. Yes, that's what I want.. A variable that is constant within a threadgroup and all the threads running in that threadgroup. But I want that same variable name to be a different value in a different threadgroup. This way all my separate tests log to their own folder. The variable is primed by a property. That property is treated as a prefix, that in each thread is appended to to create the local logdir for that threadgroup (in this case, an entire test module). I think the workaround for the UDV 'feature' is to skip using a UDV to creating the local instance of the variable and simply define the variable in a User Parameter element and maybe mark it to update every iteration. This way it is processed in the thread and the local instance of the variable name should not propogate to the other threadgroups. I simply want a value that is localized to the threadgroup that is reused by all threads in that threadgroup. Honestly its workarounds like this that have really slowed our use of jmeter. What should be relativly simple tasks you must figure out (mostly blindly) the 'jmeter way' of doing things. What appeared to be a simple way to do modular test functions (include modules) has introduced more changes into every test plan to make them unique - even if you are running them in separate threadgroups. Threadgroups are not appearing as isolated as I originally thought. -----Original Message----- From: sebb [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 13, 2008 7:06 PM To: JMeter Users List Subject: Re: Variable problems when using include controllers On 13/05/2008, Steve Kapinos <[EMAIL PROTECTED]> wrote: > I'm sorry, but that flat out makes no sense to havee UDV's be common > across the entire testplan while Variable's themselves are only local > to a singular thread. If I want the variable in another threadgroup, > I'll define it there - since I know its only going to be used locally > - it makes sense to define it locally. It's because the UDVs are processed before the test is started - they define the initial variables that are copied to all threads. The variables are intended for items that don't change during a test run, but which may change between runs. > This makes it harder and harder to script jmeter effectivly. I'm > already passing in almost a dozen properties to execute the testing > and to have to multiply that purely because I can't define a variable > per threadgroup is getting tiresome. > > Can I hack around it by defining the variable in each threadgroup in > a User Parameter Element rather then using UDV? > User Parameters are per thread. If you use values that don't change during a run, then these will be the same across the thread group. > -----Original Message----- > From: sebb [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 13, 2008 5:44 PM > To: JMeter Users List > Subject: Re: Variable problems when using include controllers > > UDVs are configuration elements, and they are processed as the test > plan is started. > > They should only be used for variables that don't change during a run. > > They are also shared between all threads in all groups - see the note > at the end of the section: > > > http://jakarta.apache.org/jmeter/usermanual/component_reference.html#U > se > r_Defined_Variables > > > On 12/05/2008, Steve Kapinos <[EMAIL PROTECTED]> wrote: > > Parent test plan is setup as > > > > Testplan > > + threadgroupPTP > > + + include controller > > + threadgroupMPS > > + + include controller > > + threadgroupVCS > > + + include controller > > + threadgroupmonitor > > + (bunch of stuff) > > > > Each include controller inserts a free-standing testplan, that > each > work independantly and test out fine on their own. > > > > Each testplan as a UDV where a variable logdir is defined as > > ${__P(p_logs-out,ptp-out)} where 'ptp-out' changes for each > testplan: > > mps-out, vcs-out, etc. ${logdir} is then used to define the > > listener's output directory for each test. Currently no p_logs-out > > property is defined, so each test should use its default assigned > > value, and this works fine when each test is ran on its own. > > > > However, when the tests are included as shown above, each included > > test executes using the same value for ${logdir} so all log files > go > into the same directory. Since variables are thread-specific > this > should not happen. They all manage to use 'vcs-out' as their > value, > so the last read in UDV for some reason is overwriting the > variable > definition for all threads, not just its own. > > > > Steve Kapinos > > Solution Developer - R&D > > TANDBERG > > > > Phone: +1 703 7094272 > > Video: [EMAIL PROTECTED] > > E-mail: [EMAIL PROTECTED] > > > > 1860 Michael Faraday Dr > > Reston, VA 20190, USA > > > > www.tandberg.com > > > > > --------------------------------------------------------------------- > > 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] > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
