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]
