On 14/05/2008, Steve Kapinos <[EMAIL PROTECTED]> wrote: > >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.
Properties were not available to the test elements when the UDV was implemented. Besides, all that happens (AIUI) is that the initial values of the UDV variables are made available to all threads. You can change them later if you really want. > 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. > Not so - this is equivalent to having class variables initialised in a Java constructor.You can update the variables later, but intially they are all the same. > > >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. You can do this, as explained above. But that is not the original purpose of UDVs (as far as I know, I was not around when this was designed) The only thing you cannot do is define variables which are shared across a threadgroup. > 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. > It's only recently that variables worked in Listener file names, so count your blessings... > >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. That you can do, so long as you define the variable using User Parameters, as I wrote last time. > 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 No need to use UDVs if they don't do what you want. > 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. As I have written already, you can do this with User Parameters. > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
