On Thursday, June 2, 2016, Pratapi Hemant Patel <[email protected]> wrote:
> From component reference page > > http://jmeter.apache.org/usermanual/component_reference.html#User_Defined_Variables > > UDVs are shared between Thread Groups Not threads > > By Default variables have thread scope, but variables defined in User > Defined Variables components have global scope. They have thread scope. What the doc says is that they exist for all thread groups. > > > With Best Regards > Hemant > 9810752184 / 9013982184 > <https://in.linkedin.com/pub/pratapi-hemant-patel/39/3b9/5a5> > > On Thu, Jun 2, 2016 at 9:37 AM, Deepak Shetty <[email protected] > <javascript:;>> wrote: > > > variables do not have "global" scope - in the sense that they are not > > shared across threads (even if the initial value could be same , changes > > are not reflected in a different thread) > > > > On Wed, Jun 1, 2016 at 8:58 PM, Pratapi Hemant Patel < > > [email protected] <javascript:;> > > > wrote: > > > > > AS far as i understand, if you want to define some variable that can be > > > shared among thread groups, use USER DEFINED VARIABLE component. The > > > variables defined in it have global scope. > > > > > > Best Regards, > > > Hemant > > > 9810752184 / 9013982184 <%209013982184> > > > On 02-Jun-2016 5:47 AM, "David Luu" <[email protected] <javascript:;>> > wrote: > > > > > > > Is there any facility in JMeter already to define code/script based > > > > configuration once for threads or thread groups to then use later on? > > > > Meaning a single execution is done to dynamically generate the needed > > > test > > > > data (and utility methods) at test startup, then this whole config > > > "object" > > > > is referenced by threads in thread groups later on during the actual > > test > > > > run. > > > > > > > > Browsing over the JMeter docs, I'm not aware if that already exists, > or > > > how > > > > best to implement this. Basically, in terms of JMeter > > extensions/plugins, > > > > I'm thinking of a config element that's like a static class or > > singleton, > > > > don't want each thread trying to instantiate their own instance. > And/or > > > > something similar to user defined variables at the test plan root > > level, > > > > only the variable is a Java object/struct rather than simple string > > (that > > > > could be typecasted to int) - or that defining the Java object is a > lot > > > of > > > > logic that can't simply be done with JMeter functions to then flatten > > > > object (serialized) to JSON string. > > > > > > > > If there already is such facility & best practice, that would be > great > > > as I > > > > don't want to have to deal with instance checking, synchronization, > and > > > > thread safety myself unless I have to, when instantiating the > globally > > > > shared data across threads. Nor do I want each thread to have their > own > > > > "copy" as that eats up memory/resources as we scale the load up. > > > > > > > > I'm currently using a Java-based config element based off the CSV > Data > > > Set > > > > Config (from kafkameter project). Would placing the config element > > under > > > > test plan rather than under a thread group affect how it executes? > E.g. > > > > execute once and result/output global to all threads, or would it > also > > be > > > > executed X times for X threads, being globally used by them all, but > > not > > > > global in the sense of being already executed once with its output > > > readily > > > > accessible? > > > > > > > > This discussion would be with respect to things like config elements, > > or > > > > say pre-processors, in Java, Beanshell, javascript - but in the > global > > > > execute once context rather than execute per thread, while providing > > its > > > > output (as JMeter variables, etc.) being global to all threads. > > > > > > > > > > -- Cordialement. Philippe Mouawad.
