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#Use > 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]
