I also think it's likely to be sparingly used.
It's just that I'm not sure that it's obvious which components would
need to be able to write the global data.
This is why I think a naming convention would be the most convenient -
simple to implement, and applicable to all test elements without
further ado.
Clashes with variable names in existing test plans could be avoided by
allowing the default global indicator marker to be changed by setting
a startup property.
I don't think it's necessary to implement a new syntax for retrieving
variables - just check local then global as you wrote earlier.
S.
On 4/27/05, Michael Stover <[EMAIL PROTECTED]> wrote:
> I'm thinking wanting data to be global is a rare thing - after all,
> we're simulating independent users most of the time, right? I would
> think wanting to write data to global is a highly specific thing that
> only a smallish number of components would do.
>
> If I'm wrong, maybe a naming convention or a new syntax could be created
> (ie %{} instead of ${} to retrieve and something for setting). I'd
> prefer it if we could conclude this would be overkill though :-)
>
> -Mike
>
> On Wed, 2005-04-27 at 22:59 +0100, sebb wrote:
> > Mostly agreed.
> >
> > But how would components know whether or not to store data globally?
> >
> > One way would be a naming convention (*).
> > Otherwise, it seems to me that every component that might want to
> > write global data would need to be extended to allow its "global" flag
> > to be set.
> >
> > (*) This could be implicit - e.g. all variables starting with G_ are
> > global - or explicit - e.g. one can define a list of global names in a
> > property or a new test element listing all the global names.
> >
> > S.
> > On 4/27/05, Michael Stover <[EMAIL PROTECTED]> wrote:
> > > 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]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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]
