It'll have to be synchronized no matter what.  Probably don't want to
extend JMeterVariables for that reason.  I would say, make writing to it
a custom thing - ie, if a component wants data put to global level, it
can write it there, or instruct JMeter context to copy it there.  For
reading, I"d say read the local variable first, if not there, look at
global, as default behavior.

-Mike

On Wed, 2005-04-27 at 22:04 +0100, sebb wrote:
> OK.
> 
> Do all variables get written to this?
> Might be expensive (access will have to be synchronized).
> If not, how are the variables chosen?
> Naming convention perhaps? 
> Otherwise a new syntax might be needed.
> 
> S.
> On 4/27/05, Michael Stover <[EMAIL PROTECTED]> wrote:
> > So why don't we just slap another JMeterVariables object in the
> > JMeterContextService class that can act as a holder for global
> > variables?  Each context has a getVariables method that retrieves the
> > variable holder for each thread, let's make a global one too.
> > 
> > -Mike
> > 
> > On Wed, 2005-04-27 at 14:18 +0100, sebb wrote:
> > > Variables are local to a thread.
> > >
> > > Properties are global to JMeter; they can easily be read using the
> > > various property functions.
> > >
> > > However, at present the only way to set them is to use BeanShell, but
> > > it would not be difficult to enhance JMeter to add a function or some
> > > other test element to set a property from a variable.
> > >
> > > S.
> > > On 4/27/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > > Hello,
> > > >
> > > > I recall a similar issue (relating to thread synchronisation) that was
> > > > discussed recently but I can't for the life of me find the e-mails, so
> > > > please forgive me if this is rehashing something that's already been
> > > > addressed.
> > > >
> > > > Here is what I am trying to accomplish in JMeter: I want to have two
> > > > thread groups. One thread group would contain a given testplan and the
> > > > second would contain another simple testplan that simply loops through a
> > > > couple requests for as long as the first thread group is running.
> > > >
> > > > My first thought was to declare a user variable that I would use as the
> > > > condition for a Loop Controller in the second thread group. When the 
> > > > first
> > > > thread group finishes, it would set the value of this variable to false
> > > > and the loop in the second thread group would exit. This does not appear
> > > > to work.
> > > >
> > > > So I guess my question is: is there a way to declare a variable that is
> > > > global to the whole testplan? and moreover, is there a better way to 
> > > > have
> > > > my two thread groups interact in a way that would accomplish what I am
> > > > trying to do?
> > > >
> > > > Thanks in advance for any insight you might have,
> > > > Vincent
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > 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