On 13/11/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote:
> Thanks Sebb: I've set the 'Label' input of a Java Request/JavaTest
> sampler in the first thread group to:
>        ${__setProperty(property,${variable})}
> This successfully sets the property to the variable value; I can now use
> it in the second thread group.
>
> Is this behaviour of User Defined Variables (in my earlier testplan
> below) worth a bugzilla entry?

No, I don't think it's a bug.

> > 'HTTP Sampler 2' is just a dummy request that appears to 'fix' the
> > property set in thread 1. If I remove that sampler, the property
> appears
> > as '${some_jmeter_variable}' (instead of the JMeter variable's value)
> > the second thread group.
>
> Thanks & regards,
> Sonam Chauhan
> --
> Corporate Express Australia Ltd.
> Phone: +61-2-93350725, Email: [EMAIL PROTECTED]
>
>
> -----Original Message-----
> From: sebb [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 13 November 2007 2:17 PM
> To: JMeter Users List
> Subject: Re: How can JMeter variables be shared between thread groups?
>
> On 13/11/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote:
> > Hi Sebb:
> >
> > > That should work. At the very least the property should be set to
> > >
> > > ${some_jmeter_variable }
> > Yes, that's what the string that it evaluates to.
> >
> > > BTW, is the trailing space present in the test plan?
> > Sorry for the confusion, the trailing space wasn't in the test plan.
> >
> >
> > I was just gonna write to say I tried the 'User Defined Variables'
> > Config Element instead of the 'User Parameter' Pre-Processor, and it
> got
> > it working (along with what appears to be a bug).
>
> RE is a Post-Processor, and happens after a sample.
>
> User Parameters is a Pre-Processor, and only happens before a sample.
>
> > Here's my test plan:
> > -------------------------------------
> > Thread 1 (1 thread)
> > - HTTP Sampler 1
> >  --  Regex Extractor 1(Initialize some_jmeter_variable)
> > - User Defined Variables 1 (Set some_property = some_jmeter_variable)
> > - HTTP Sampler 2 (Dummy Request that uses property set above)
>
> You could just use a Java Request with the __setProperty() in one of the
> fields.
>
> > Thread 2 (multiple threads)
> > - HTTP Sampler 3 (Real request that uses property set above)
> > -------------------------------------
> >
> > This finally does work.
> >
> > 'HTTP Sampler 2' is just a dummy request that appears to 'fix' the
> > property set in thread 1. If I remove that sampler, the property
> appears
> > as '${some_jmeter_variable}' (instead of the JMeter variable's value)
> > the second thread group.
> >
> > Is this a bug? I am using 2.1.1.
> >
> > Kind regards,
> > Sonam Chauhan
> > --
> > Corporate Express Australia Ltd.
> > Phone: +61-2-93350725, Email: [EMAIL PROTECTED]
> >
> > -----Original Message-----
> > From: sebb [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, 13 November 2007 1:58 PM
> > To: JMeter Users List
> > Subject: Re: How can JMeter variables be shared between thread groups?
> >
> > On 13/11/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote:
> > > Thanks Sebb.
> > >
> > > > JMeter properties are gobal. You can use the __setProperty()
> > function
> > > > to set a property.
> > >
> > > Can I set a property to the value of a JMeter variable? I tried the
> >
> > Yes.
> >
> > > following in a User Parameter element, but it doesn't seem to work
> (at
> > > least in 2.1.1):
> > >
> > >        ${__setProperty(some_property,${some_jmeter_variable })}
> >
> > That should work. At the very least the property should be set to
> >
> >  ${some_jmeter_variable }
> >
> > Check jmeter.log
> >
> > BTW, is the trailing space present in the test plan?
> >
> > > Is there any other way to exchange run-time data between threads?
> >
> > Not without using BeanShell or otherwise writing code.
> >
> > Threads are supposed to be independent ...
> >
> > > Kind regards,
> >
> > > Sonam Chauhan
> > > --
> > > Corporate Express Australia Ltd.
> > > Phone: +61-2-93350725, Email: [EMAIL PROTECTED]
> > >
> > > -----Original Message-----
> > > From: sebb [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, 13 November 2007 1:09 PM
> > > To: JMeter Users List
> > > Subject: Re: How can JMeter variables be shared between thread
> groups?
> > >
> > > On 13/11/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote:
> > > > Can JMeter variables be shared between thread groups?
> > > >
> > >
> > > No; JMeter variables are per-thread.
> > >
> > > The initial settings are copied to all threads when the threads are
> > > created; thereafter the variables are independent. That is essential
> > > to allow threads to process RE extractors etc independently.
> > >
> > > JMeter properties are gobal. You can use the __setProperty()
> function
> > > to set a property.
> > >
> > > >
> > > > A regression testcase I am building needs to 'scrape' a variable
> > from
> > > a
> > > > webpage _only once_, then use it the scraped variable in load
> > testing
> > > > another webservice. So I built a testcase with 2 thread groups
> with
> > > 'Run
> > > > each Thread Group separately' ticked in the test plan. The first
> > > thread
> > > > group runs just one thread - an HTTP request with a Regular
> > Expression
> > > > Extractor that 'scrapes' a webpage to initializes a JMeter
> variable
> > > > reference.
> > > >
> > > >
> > > >
> > > > The second thread has multiple threads using the JMeter variable
> > > scraped
> > > > from the first thread group. However, I found the JMeter variable
> is
> > > > successfully initialized in the first thread, but not passed to
> the
> > > > second thread group. Is that expected behaviour? I am using JMeter
> > > 2.1.1
> > > >
> > > >
> > > >
> > > > Kind regards,
> > > >
> > > > Sonam Chauhan
> > > >
> > > > --
> > > >
> > > > Corporate Express Australia Ltd.
> > > >
> > > > Phone: +61-2-93350725, Email: [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]
>
>
> ---------------------------------------------------------------------
> 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]

Reply via email to