jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Epp, J Wyatt" <j...@cas.org>
Subject RE: Having a globalVariables shared accross threads
Date Tue, 31 Oct 2017 22:43:02 GMT
> -----Original Message-----
> From: Philippe Mouawad [mailto:philippe.mouawad@gmail.com]
> Sent: Tuesday, 31 October, 2017 13:55
> To: dev@jmeter.apache.org
> Subject: Re: Having a globalVariables shared accross threads
>
> On Tue, Oct 31, 2017 at 5:27 PM, Epp, J Wyatt <jepp@cas.org> wrote:
>
>> As far as the implementation, I see this as complementary to the existing
>> UserDefinedVariables in the TestPlan, so wouldn't it be better to reuse
>> the existing valueReplacer infrastructure as much as possible for this
>> effort?  (I was going to suggest encoding the variable scope as part of
>> the type, but it looks like they're just simple key-value pairs
>> (Map<String, String>). Oh well.)
>
> Can you illustrate this ? it's not clear for me.

What I mean is, if we think about "user variable" as a type of object, the
state of its scope would arise naturally, either from an additional field of
the object or maybe through modifiers (e.g. the shared keyword).

As kv pairs, they don't have a type identity of their own, really, and you
can't simply add to them.

This isn't to say you couldn't use the valueReplacer bits anyway, just keep
two separate Map<S,S> for local and shared vars.
>> Alternatively, it might be better to simply improve properties by exposing
>> UI
>
> You mean a sort of User Defined Properties  ?

Essentially.  Properties are already global, from what I recall.

>> ... Actually, thinking of some things I've tried to do myself, I think
>> the ability to define and set properties dynamically, then use them with
>> a similar sort of shorthand as regular thread-local varibles would be
>> even more potent than simple global variables.  Please consider it.
>
> Currently they are used like this ${__P(propName)} .

I admit, I had actually forgotten that.  On the other hand, I don't
especially like that it's separate syntax from regular variables.  Not
terribly important to this discussion.

> It is true that the difference between vars and props is not evident for
> everybody when starting JMeter. So there is room for improvement.

It doesn't help that the UX for properties is very suboptimal.  They lack
discoverability and cannot be easily modified without changing the command
line or the properties file (and restarting JMeter).  Considering the power
they afford, I'd really like to see them have better exposure from the GUI
(if nothing else).  Maybe something like about:config in browsers...

> Having a global prefix is kind of meaningful as it clearly states that
> they are shared, so I like the idea.

If there's no other way, I guess it's fine.  Encoding scope in the name is
some nasty code smell, though; can it not be done some other way?

> This could be manipulated this way:
> ${global:propName}
> vars.put("global:propName", "value"); or vars.putGlobal("propName",
> "value"); or both ?

We should be able to infer scope.  Leaving it up to the user is just begging
for weird bug reports. It should be clean.

${propName}

If an identifier exists in local and global scope it should be considered an
error.  Clobbering is generally bad in these contexts.

Since the symbol search space is naturally the union of local and global
scope, the put() method SHOULD just check them in-turn and handle it
appropriately. This should Just Work:

vars.put("propName", "value");

Okay, that works for an update.  But what about declaration?  If it's local,
everything is fine, business as usual.  Local MUST be default.  If you need
it to be global... would an optional argument to put() be acceptable?

vars.put("propName", "global_value", GLOBAL); // Just use an enum.

That's what I'm thinking, at least.

> Also what would be the difference with properties ?  I initially had in
> mind to make Global vars related to test life cycle.  Properties are not
> like this and some properties are read on class loading and their
> modification is useless afterwards.

That's a fair question. I suppose we must first ask: what precisely _is_ a
property? What sets it apart from a variable?

The manual states the following:

"Properties are not the same as variables. Variables are local to a thread;
properties are common to all threads, and need to be referenced using the
__P or __property function."

So the difference is properties are global?  Huh.  Okay.

Later, there's __P(), __property(), and __setProperty(), which encompass
much of what's being talked about here.  That would seem to support the
thought that much of what we need is just porcelain around the plumbing.
(Bluntly, having to wrap everything in accessor functions kind of sucks.)

But then, as you note, some properties have a de facto immutability because
of class loading. (I wonder how many of those can be fixed?)  This implies
that, at least conceptually, we give properties the weight of truth when it
comes to how the application behaves.

So we find there's a conflation of two purposes.

Where does this leave us?  With several paths to the same end.  Whoops. ;)

Maybe this could be the tiebreaker:
What would make it easier to move toward lexically scoped user vars?  And
then after that, repeatable ArgumentsPanel execution? Because I'd very much
love to see that.

Regards,
Wyatt

Confidentiality Notice: This electronic message transmission, including any attachment(s),
may contain confidential, proprietary, or privileged information from Chemical Abstracts Service
("CAS"), a division of the American Chemical Society ("ACS"). If you have received this transmission
in error, be advised that any disclosure, copying, distribution, or use of the contents of
this information is strictly prohibited. Please destroy all copies of the message and contact
the sender immediately by either replying to this message or calling 614-447-3600.

Mime
View raw message