RE: Having a globalVariables shared accross threads

[Epp, J Wyatt]

> -Original Message-
> From: Philippe Mouawad [mailto:philippe.moua...@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  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). 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 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:
Wha

Re: Having a globalVariables shared accross threads

[Philippe Mouawad]

On Tue, Oct 31, 2017 at 5:27 PM, Epp, J Wyatt  wrote:

> > -Original Message-
> > From: Philippe Mouawad [mailto:philippe.moua...@gmail.com]
> > Sent: Friday, 27 October, 2017 03:08
> > To: dev@jmeter.apache.org
> > Subject: Re: Having a globalVariables shared accross threads
> >
> > Created :
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=61674
>
> This is a good effort.  I think in the interest of usability it would be
> preferable if the global: prefix wasn't needed, but maybe that can be
> addressed
> later.
>
> 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). Oh
> well.)
>

Can you illustrate this ? it's not clear for me.

>
> Alternatively, it might be better to simply improve properties by exposing
> UI
>

You mean a sort of User Defined Properties  ?

> and API for properly working with them.



> Looking at the class definition for
> JMeterVariables (from your proposal), the comment at the top of the module
> even
> says:
>
> /**
>  * Class which defines JMeter variables.
>  * These are similar to properties, but they are local to a single thread.
>  */
>
> So unless there's some nuance I've missed, what you need already mostly
> exists,
> but it has a bad workflow and some of the details need work.
>

Yes, I don't know why, when I started increasing coverage, I  used
Beanshell to do that :-).
So I started this discussion and then I remembered it was possible and
fixed the coverage but didn't update discussion.




>
> ... 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)} .

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

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

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

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.



> Cheers,
> 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.
>
>


-- 
Cordialement.
Philippe Mouawad.

RE: Having a globalVariables shared accross threads

[Epp, J Wyatt]

> -Original Message-
> From: Philippe Mouawad [mailto:philippe.moua...@gmail.com]
> Sent: Friday, 27 October, 2017 03:08
> To: dev@jmeter.apache.org
> Subject: Re: Having a globalVariables shared accross threads
> 
> Created :
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61674

This is a good effort.  I think in the interest of usability it would be
preferable if the global: prefix wasn't needed, but maybe that can be addressed
later.

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). Oh well.)

Alternatively, it might be better to simply improve properties by exposing UI
and API for properly working with them.  Looking at the class definition for
JMeterVariables (from your proposal), the comment at the top of the module even
says:

/**
 * Class which defines JMeter variables.
 * These are similar to properties, but they are local to a single thread.
 */

So unless there's some nuance I've missed, what you need already mostly exists,
but it has a bad workflow and some of the details need work.

... 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.

Cheers,
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.

RE: Some JMeter (technical) concerns

[Epp, J Wyatt]

> -Original Message-
> From: Emilian Bold [mailto:emilian.b...@protonmail.ch]
> Sent: Monday, 30 October, 2017 08:27
> To: dev@jmeter.apache.org
> Subject: Some JMeter (technical) concerns
> 
> Compared to some of the plugins, JMeter seems to move very slowly. This
> might create the impression of stability but I believe it's just a sign of
> being resource constrained.

Workflow matters.  Good tooling and process can allow a comparatively small
number of people hit well above their weight class.  Someone needs to lead
the charge, though.

FWIW, In the time I've been following the project, it's definitely improved.

> Generally speaking, it would be good to split the UI from the "core" so we
> have some path where we evolve to some other UI.

Speaking from an engineering standpoint, I view the tight coupling of the
GUI to the internal representation and core functionality as _THE_ primary
long term blocker for the viability of the JMeter project as a whole.

> I find the whole configuration .properties file a very poor solution to
> the notion of a "project".

I think this is just another side effect of the tight coupling.

> The whole communication between JMeter client and servers should be
> rewritten using more modern protocols.

For this, I think the most important thing to pay attention to is the
usability and efficiency. Distributed execution of sophisticated test plans
is a 10x Advantage of JMeter; to my knowledge, this is the only tool that
can do it. So it'd be wise capitalise on that by making sure anyone else who
comes into this area has a tall order to be anything other than an also-ran.

> JMeter should think more about making it easy to be hooked up into a CI /
> CD pipeline.

Another place the GUI coupling hurts.  I've recently been prototyping moving
our internal tooling to Gatling in large part because working with the
JMeter APIs is fraught with hazards and weird edge cases.

> The XML files are a pain to diff and people like to track / compare
> changes in modern devops shops.

More to the point, they're another coupling problem because they're a
serialisation.  I have zero love for the JMX format after having to write
tools that work with it.  Perhaps surprisingly, I think this _could_ be
resolved nicely without all of the other core work (rather, this would
probably facilitate that).

But it requires knowing what needs to be supported, first. (It ends up being
a language design problem.)

> Maybe a switch to YAML might suffice

Nah, that's just trading one ugly markup for another. Been done already.

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.

Jenkins build is back to normal : JMeter-trunk #6414

[Apache Jenkins Server]

See 

Re: Opinion on this potential new look for JMeter UI

[Andrey Pokhilko]

Like!

Andrey Pokhilko

31.10.2017 17:02, Philippe Mouawad пишет:
> Hello,
> Your opinion is welcome on this new Look proposal for JMeter UI:
>
> - https://twitter.com/ApacheJMeter/status/925357635066572800
>
> Thanks for expressing yourselves at this link or directly here.
>
> Regards
> Philippe M. on behalf of Apache JMeter Team
> https://twitter.com/ApacheJMeter/status/925357635066572800
>

Re: Opinion on this potential new look for JMeter UI

[Antonio Gomes Rodrigues]

Hi,

A lot of other Swing application use it.

I will test it in Windows and Linux asap

Antonio

2017-10-31 15:02 GMT+01:00 Philippe Mouawad :

> Hello,
> Your opinion is welcome on this new Look proposal for JMeter UI:
>
> - https://twitter.com/ApacheJMeter/status/925357635066572800
>
> Thanks for expressing yourselves at this link or directly here.
>
> Regards
> Philippe M. on behalf of Apache JMeter Team
> https://twitter.com/ApacheJMeter/status/925357635066572800
>

Re: Integrating Darcula LAF as JMeter main LAF

[Philippe Mouawad]

For follow up:
https://bz.apache.org/bugzilla/show_bug.cgi?id=61697

On Mon, Oct 30, 2017 at 8:07 PM, Emilian Bold 
wrote:

> Yes, sadly the project is not in Maven Central, which is annoying. I use
> Maven for YaMeter and the Darcula JAR needs special treatment since it's
> local...
>
> --emi
>
> > Original Message 
> >Subject: Integrating Darcula LAF as JMeter main LAF
> >Local Time: October 30, 2017 8:28 PM
> >UTC Time: October 30, 2017 6:28 PM
> >From: philippe.moua...@gmail.com
> >To: dev@jmeter.apache.org 
> >
> >Hello,
> > Following Emilian Bold suggestion about Darcula LAF, I've had a look at
> it.
> > Integration seems easy.
> >
> > But I see 2 minor to major problems:
> > - Library does not seem to have a versioning system:
> > - https://github.com/bulenkov/Darcula/issues/40
> > - There is no maven artifact :
> > - https://github.com/bulenkov/Darcula/issues/7
> > - There seems to be an issue with Java9, but I think this one is not a
> > problem
> >
> > But I'll move towards integration by for now managing a download as we do
> > for Checkstyle.
> > The JAR is available at:
> > - https://github.com/bulenkov/Darcula/raw/master/build/darcula.jar
> >
> > My main concern is that it's not versioned clearly but I think we can
> work
> > with commits ids:
> > -
> >https://github.com/bulenkov/Darcula/blob/e208efb96f70e4be9dc362fbb46f6e
> 181ef501dd/build/darcula.jar
> >
> >
> > If I am wrong, please correct me here.
> > Thanks
> >
> >Cordialement.
> > Philippe Mouawad.
> >




-- 
Cordialement.
Philippe Mouawad.

buildbot success in on jmeter-trunk

[buildbot]

The Buildbot has detected a restored build on builder jmeter-trunk while 
building . Full details are available at:
https://ci.apache.org/builders/jmeter-trunk/builds/3115

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: bb_slave1_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-jmeter-commit' 
triggered this build
Build Source Stamp: [branch jmeter/trunk] 1813884
Blamelist: pmouawad

Build succeeded!

Sincerely,
 -The Buildbot

Opinion on this potential new look for JMeter UI

[Philippe Mouawad]

Hello,
Your opinion is welcome on this new Look proposal for JMeter UI:

- https://twitter.com/ApacheJMeter/status/925357635066572800

Thanks for expressing yourselves at this link or directly here.

Regards
Philippe M. on behalf of Apache JMeter Team
https://twitter.com/ApacheJMeter/status/925357635066572800

Build failed in Jenkins: JMeter-trunk #6413

[Apache Jenkins Server]

See 


Changes:

[pmouawad] Bug 61704 - Toolbar : Improve a bit the right part
Bugzilla Id: 61704

--
[...truncated 134.46 KB...]
  [javadoc] Loading source files for package org.apache.jmeter.functions.util...
  [javadoc] Loading source files for package org.apache.jmeter.gui...
  [javadoc] Loading source files for package org.apache.jmeter.gui.action...
  [javadoc] Loading source files for package 
org.apache.jmeter.gui.action.impl...
  [javadoc] Loading source files for package 
org.apache.jmeter.gui.action.template...
  [javadoc] Loading source files for package 
org.apache.jmeter.gui.action.thinktime...
  [javadoc] Loading source files for package 
org.apache.jmeter.gui.action.validation...
  [javadoc] Loading source files for package org.apache.jmeter.gui.logging...
  [javadoc] Loading source files for package org.apache.jmeter.gui.plugin...
  [javadoc] Loading source files for package org.apache.jmeter.gui.tree...
  [javadoc] Loading source files for package org.apache.jmeter.gui.util...
  [javadoc] Loading source files for package org.apache.jmeter.plugin...
  [javadoc] Loading source files for package org.apache.jmeter.processor...
  [javadoc] Loading source files for package org.apache.jmeter.processor.gui...
  [javadoc] Loading source files for package org.apache.jmeter.report.config...
  [javadoc] Loading source files for package org.apache.jmeter.report.core...
  [javadoc] Loading source files for package 
org.apache.jmeter.report.dashboard...
  [javadoc] Loading source files for package 
org.apache.jmeter.report.processor...
  [javadoc] Loading source files for package 
org.apache.jmeter.report.processor.graph...
  [javadoc] Loading source files for package 
org.apache.jmeter.report.processor.graph.impl...
  [javadoc] Loading source files for package org.apache.jmeter.reporters...
  [javadoc] Loading source files for package org.apache.jmeter.reporters.gui...
  [javadoc] Loading source files for package org.apache.jmeter.samplers...
  [javadoc] Loading source files for package org.apache.jmeter.samplers.gui...
  [javadoc] Loading source files for package org.apache.jmeter.save...
  [javadoc] Loading source files for package 
org.apache.jmeter.save.converters...
  [javadoc] Loading source files for package org.apache.jmeter.services...
  [javadoc] Loading source files for package org.apache.jmeter.swing...
  [javadoc] Loading source files for package org.apache.jmeter.testbeans...
  [javadoc] Loading source files for package org.apache.jmeter.testbeans.gui...
  [javadoc] Loading source files for package org.apache.jmeter.testelement...
  [javadoc] Loading source files for package 
org.apache.jmeter.testelement.property...
  [javadoc] Loading source files for package org.apache.jmeter.threads...
  [javadoc] Loading source files for package org.apache.jmeter.threads.gui...
  [javadoc] Loading source files for package org.apache.jmeter.timers...
  [javadoc] Loading source files for package org.apache.jmeter.timers.gui...
  [javadoc] Loading source files for package org.apache.jmeter.util...
  [javadoc] Loading source files for package org.apache.jmeter.util.keystore...
  [javadoc] Loading source files for package org.apache.jmeter.visualizers...
  [javadoc] Loading source files for package 
org.apache.jmeter.visualizers.backend...
  [javadoc] Loading source files for package 
org.apache.jmeter.visualizers.gui...
  [javadoc] Loading source files for package org.apache.jmeter.extractor...
  [javadoc] Loading source files for package org.apache.jmeter.extractor.gui...
  [javadoc] Loading source files for package 
org.apache.jmeter.extractor.json.jsonpath...
  [javadoc] Loading source files for package 
org.apache.jmeter.extractor.json.jsonpath.gui...
  [javadoc] Loading source files for package 
org.apache.jmeter.extractor.json.render...
  [javadoc] Loading source files for package org.apache.jmeter.modifiers...
  [javadoc] Loading source files for package org.apache.jmeter.modifiers.gui...
  [javadoc] Loading source files for package org.apache.jmeter.sampler...
  [javadoc] Loading source files for package org.apache.jmeter.sampler.gui...
  [javadoc] Loading source files for package org.apache.jmeter.thinktime...
  [javadoc] Loading source files for package org.apache.jmeter.validation...
  [javadoc] Loading source files for package 
org.apache.jmeter.visualizers.backend.graphite...
  [javadoc] Loading source files for package 
org.apache.jmeter.visualizers.backend.influxdb...
  [javadoc] Loading source files for package 
org.apache.jmeter.visualizers.utils...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.http.config...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.http.config.gui...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.http.control...
  [javadoc] Loading source files for package 
org.apache.j

buildbot failure in on jmeter-trunk

[buildbot]

The Buildbot has detected a new failure on builder jmeter-trunk while building 
. Full details are available at:
https://ci.apache.org/builders/jmeter-trunk/builds/3114

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: bb_slave1_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-jmeter-commit' 
triggered this build
Build Source Stamp: [branch jmeter/trunk] 1813882
Blamelist: pmouawad

BUILD FAILED: failed shell_3

Sincerely,
 -The Buildbot