MQTT Sampler and future JMeter work

[Philippe Mouawad]

Hello,
Once 3.1 is released, should we merge this PR in JMeter ?

I think we should provided all rights issues ( I think the PR is a fork of
another implementation) are ok.

IOT is the future and I start to see commercial offers proposing MQTT from
Sas solutions


We should by the way really start working on:
- http2
- websocket

I raised in the past an idea about asking for help from Community as per
Apche policy, what do you think about it ?

Another thing to look at would be to prticipate to google summer of code
and mentor somebody to work on this.

What's your opinions ?

Thanks
Regards

FOr information a twitter

On Thu, Feb 11, 2016 at 6:08 AM, Hemika Kodikara > wrote:

> Hi,
>
> In my opinion having a MQTT sampler is very useful. I have seen several
> discussions(mails and PRs) on jmeter where an MQTT sampler is proposed.
>
> There are multiple message brokers out there which supports MQTT protocol.
> Some are ActiveMQ, HiveMQ, IBM MessageSight, Mosquitto, RabbitMQ, WSO2
> Message Broker. Performance testing and finding out numbers is the
> competing criteria among message brokers. Therefore having an MQTT sampler
> through JMeter is advantageous in my point of view.
>
> It is not only that message brokers that use MQTT protocol. Several other
> IoT devices also use the MQTT protocol [1] for application purposes.
>
> [1] -
> https://dzone.com/articles/iot-software-platform-
> comparison?utm_medium=feed_source=feedpress.me_
> campaign=Feed:%20dzone
>
> Regards,
> Hemika
>
> On Wed, Feb 3, 2016 at 4:28 AM, sebb  > wrote:
>
> > Is there really a sufficient use case that we need to include it in core?
> >
> > How many developers are familiar with the protocol and can maintain
> > the code and answer user queries?
> >
> > On 2 February 2016 at 22:49, Philippe Mouawad
> >  > wrote:
> > > Hi ,
> > > Any thoughts on this ?
> > >
> > > Thanks
> > >
> > > On Monday, January 25, 2016, Philippe Mouawad <
> > philippe.moua...@gmail.com
> >
> > > wrote:
> > >
> > >> Hello,
> > >> As you know we received a PR request for MQTT sampler.
> > >> Before we go further (contact the forked MQTT Sampler project to know
> if
> > >> they agree to provide it to core, I think it is necessary no ?),
> > >> what's your opinion on it ?
> > >>
> > >> Should it be integrated in core ?
> > >>
> > >> My opinion is yes.
> > >>
> > >>
> > >> Regards
> > >> Philippe
> > >>
> > >
> > >
> > > --
> > > Cordialement.
> > > Philippe Mouawad.
> >
>



-- 
Cordialement.
Philippe Mouawad.




-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 3.1 RC3

[Antonio Gomes Rodrigues]

Hi,

Tested in Windows 10 and linux fedora 24

+1

Regards,
Antonio

2016-11-14 12:44 GMT+01:00 Felix Schumacher <
felix.schumac...@internetallee.de>:

>
>
> Am 13. November 2016 20:34:16 MEZ, schrieb Milamber :
> >Hello,
> >
> >The third release candidate for JMeter 3.1 (r1769531) has been
> >prepared,
> >and your votes are solicited.
> >
> >This release brings new features and fixes bugs.
> >
> >Please, test this release candidate (with load tests and/or functional
> >tests) using Java 7/8 on Linux/Windows/Mac OS, especially on the
> >changes. The feedback are welcome.
> >
> >You can read the New and Noteworthy section with some screenshots to
> >illustrate improvements and full list of changes at:
> >http://home.apache.org/~milamber/jmeter-3.1RC3/docs/changes.html
> >
> >JMeter is a Java desktop application designed to load test functional
> >behavior and measure performance. The current version is targeted at
> >Java 7+.
> >
> >Download - Archives/hashes/sigs:
> >
> >https://dist.apache.org/repos/dist/dev/jmeter/v3.1_RC3/
> >(dist revision r16985)
> >
> >RAT report:
> >
> >http://home.apache.org/~milamber/jmeter-3.1RC3/dist/
> rat-report-jmeter-3.1RC3.txt
> >
> >MD5 hashes of archives for this vote:
> >
> >37e3c75cf80d2c60444e429bb0c27ae6 *apache-jmeter-3.1.tgz
> >f096f4991454a22850ec6174331cfeed *apache-jmeter-3.1.zip
> >a3e308d541a6c077ec322bce0d699a77 *apache-jmeter-3.1_src.tgz
> >96b94f4e0189bd0aa6e578e80323e6b7 *apache-jmeter-3.1_src.zip
> >
> >Site Docs are here:
> >http://home.apache.org/~milamber/jmeter-3.1RC3/docs/
> >
> >Maven staging repository is accessible here:
> >https://repository.apache.org/content/repositories/
> orgapachejmeter-1013/org/apache/jmeter/
> >
> >Tag:
> >https://svn.apache.org/repos/asf/jmeter/tags/v3_1_RC3/
> >
> >Keys are here:
> >https://www.apache.org/dist/jmeter/KEYS
> >
> >N.B.
> >To download the dependencies: "ant download_jars"
> >
> >To create the jars and test JMeter: "ant package test".
> >
> >JMeter 3.1 requires Java 7 or later to run.
> >
> >Some known issues and incompatible changes are listed on changes page.
> >http://home.apache.org/~milamber/jmeter-3.1RC3/docs/
> changes.html#Known%20problems%20and%20workarounds
> >
> >
> >All feedback and vote are welcome.
> >
> >[x] +1  I support this release
> >[  ] +0  I am OK with this release
> >[  ] -0   OK, but
> >[  ] -1   I do not support this release (please indicate why)
> >
> >The vote will remain open for at least 72 hours.
> >
> >The PMC members please indicate the mention "(binding)" with your vote.
>
> +1
>
> Regards,
>   Felix (binding)
>
> >
> >
> >Note: If the vote passes, the intention is to release the archive files
> >and rename the RC tag as the release tag.
> >
> >Thanks in advance!
> >
> >Milamber
>
>

RE: How should no-op setter methods be filed in Bugzilla?

[Epp, Jeremiah W (Contractor)]

> -Original Message-
> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
> Sent: Monday, November 14, 2016 10:11 AM
> To: dev@jmeter.apache.org
> Subject: Re: How should no-op setter methods be filed in Bugzilla?
>
> I have attached a test case that models this, with the only downside,
> that it works with current trunk.

Thank you, though I have to admit I'm not sure how to correctly run that.
Unfortunately, nor do I really have time to get deep in this problem right
now.  The example was really just to show the _class_ of problem I've had to
work around. There have been a slew of these.

But, looking at the code real quick gives me an idea...

Okay, that does help narrow it down.  Using the getter and setter methods
works fine... at runtime.  But there's something janky in how JMX export is
working.  Whether it's in JMeter or my own code, I'm not really sure, but if
we don't set the actual properties, they don't get saved in the output.

Let's try this: if you were going to export those postProcessors in your
test to a JMX file on the disk, what would the code look like?

> Which version of JMeter do you use?

Just vanilla 3.0 (previously, 2.13). 3.1 once it comes out.  Really, there's
nothing special going on here.

> If you think the api doesn't work as it should, you could first try to
> discuss it here on the mailing list, or if it is really a no-brainer,
> submit a bug. It would be superb, if you could provide a test case showing
> the error.

I was thinking this was pretty open-and-shut.  It may still be, but that's
less clear. I guess it really depends on what we settle on as the real bug
in this case.  That'll inform how I file 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: How should no-op setter methods be filed in Bugzilla?

[Felix Schumacher]

Am 14.11.2016 14:47, schrieb Epp, Jeremiah W (Contractor):
While working on our load automation tooling, I've had to figure out a 
lot
of obscure and relatively undocumented things about the JMeter 
internals.
One of the more bizarre things I've run into is a bunch of setter 
methods
that apparently just don't work, forcing you to use setProperty() in a 
bunch

of places instead.  It's really annoying.

Example:
JSR223PostProcessor jsr = new JSR223PostProcessor();
jsr. setScriptLanguage("beanshell");   // This doesn't actually do 
anything.
jsr. setProperty("scriptLanguage", "beanshell"); // We have to use 
this.


I have attached a test case that models this, with the only downside, 
that it works with current trunk.
Which version of JMeter do you use? And is the test broken with your 
sources?




I realised last Friday (after hitting two more) that I should probably 
be
reporting these, but I wanted to check on the list first about how we 
want
them in Bugzilla.  Should each method have a bug?  Each class?  Should 
there

be a tracking bug for them?  A bz Keyword?  Please advise.


If you think the api doesn't work as it should, you could first try to 
discuss it here on the mailing list, or if it is really a no-brainer, 
submit a bug. It would be superb, if you could provide a test case 
showing the error.


On the scope of the bug. Judge yourself. I prefer to have simple bug 
reports.


Regards,
 Felix



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.
package org.apache.jmeter.extractor;

import static org.junit.Assert.assertThat;

import org.apache.jmeter.samplers.SampleResult;
import org.apache.jmeter.threads.JMeterContext;
import org.apache.jmeter.threads.JMeterContextService;
import org.apache.jmeter.threads.JMeterVariables;
import org.hamcrest.CoreMatchers;
import org.junit.Test;

public class JSR223PostProcessorTest {

@Test
public void testGetScriptLanguage() {
JSR223PostProcessor processor = new JSR223PostProcessor();
processor.setScriptLanguage("JavaScript");
assertThat(processor.getScriptLanguage(), 
CoreMatchers.is("JavaScript"));
processor.setScriptLanguage("BeanShell");
assertThat(processor.getScriptLanguage(), CoreMatchers.is("BeanShell"));
}

@Test
public void testProcessDefaultLanguage() throws Exception {
JSR223PostProcessor processor = new JSR223PostProcessor();
processor.setScript("def answer = 1+2+3+5+7+11+13; vars.put('result', 
''+answer)");
processor.setThreadContext(initialContext());
processor.process();
assertThat(processor.getThreadContext().getVariables().get("result"), 
CoreMatchers.is("42"));
}

@Test
public void testProcessJS() throws Exception {
JSR223PostProcessor processor = new JSR223PostProcessor();
processor.setScriptLanguage("JavaScript");
processor.setScript("var answer = 1+2+3+5+7+11+13; vars.put('result', 
''+answer)");
processor.setThreadContext(initialContext());
processor.process();
assertThat(processor.getThreadContext().getVariables().get("result"), 
CoreMatchers.is("42"));
}

private JMeterContext initialContext() {
JMeterContext context = JMeterContextService.getContext();
context.setPreviousResult(new SampleResult());
context.setVariables(new JMeterVariables());
return context;
}

}

Re: Error Prone (static analysis tool for Java that catches common programming mistakes) results

[Antonio Gomes Rodrigues]

Hi,

I will fix all the warning I can after 3.1 release

Antonio

2016-10-31 22:09 GMT+01:00 Philippe Mouawad :

> Hi Antonio,
> My answers below.
> Do you have the full report ?
> Thanks
>
> On Thu, Oct 27, 2016 at 2:46 PM, Antonio Gomes Rodrigues  >
> wrote:
>
> > Hi all,
> >
> > I have run Error Prone in JMeter source code
> >
> >
> >  It have found  2 [ReferenceEquality] Comparison using reference
> > equality instead of value equality
> > http://errorprone.info/bugpattern/ReferenceEquality
> >
> >
> > [javac]
> > C:\Util\0_perso\TestError\trunk\src\core\org\apache\jmeter\samplers\
> > SampleSaveConfiguration.java:600:
> > warning: [ReferenceEquality] Comparison using reference equality instead
> of
> > value equality
> > [javac] stringValues = s.delimiter == delimiter ||
> > (delimiter != null && delimiter.equals(s.delimiter));
> > [javac]^
> > [javac] (see http://errorprone.info/bugpattern/ReferenceEquality
> )
> > [javac]   Did you mean 'stringValues = Objects.equals(s.delimiter,
> > delimiter) || (delimiter != null && delimiter.equals(s.delimiter));' or
> > 'stringValues = s.delimiter.equals(delimiter) || (delimiter != null &&
> > delimiter.equals(s.delimiter));'?
> > [javac]
> > C:\Util\0_perso\TestError\trunk\src\core\org\apache\jmeter\samplers\
> > SampleSaveConfiguration.java:604:
> > warning: [ReferenceEquality] Comparison using reference equality instead
> of
> > value equality
> > [javac] complexValues = s.formatter == formatter ||
> > (formatter != null && formatter.equals(s.formatter));
> > [javac] ^
> > [javac] (see http://errorprone.info/bugpattern/ReferenceEquality
> )
> > [javac]   Did you mean 'complexValues = Objects.equals(s.formatter,
> > formatter) || (formatter != null && formatter.equals(s.formatter));' or
> > 'complexValues = s.formatter.equals(formatter) || (formatter != null &&
> > formatter.equals(s.formatter));'?
> >
> >
> > I don't think there's a bug, but we could use Objects.equals to reduce
> syntax
>
> >
> > And some [ClassNewInstance] Class.newInstance() bypasses exception
> > checking; prefer getConstructor().newInstance()
> > http://errorprone.info/bugpattern/ClassNewInstance
> >
> > [javac]
> > C:\Util\0_perso\TestError\trunk\src\core\org\apache\
> > jmeter\testelement\property\MapProperty.java:119:
> > warning: [ClassNewInstance] Class.newInstance() bypasses exception
> > checking; prefer getConstructor().newInstance()
> > [javac] Map newCol =
> > value.getClass().newInstance();
> >
> > [javac]
> > ^
> > [javac] (see http://errorprone.info/bugpattern/ClassNewInstance)
> > [javac]   Did you mean 'Map newCol =
> > value.getClass().getConstructor().newInstance();'?
> >
>
> We should fix that at least for Java 9.
> We have something like 60 occurences
>
> >
> >
> > 1 Synchronizing on non-final fields is not safe: if the field is ever
> > updated, different threads may end up locking on different objects
> > http://errorprone.info/bugpattern/SynchronizeOnNonFinalField
> >
> > [javac]
> > C:\Util\0_perso\TestError\trunk\src\core\org\apache\
> > jmeter\reporters\Summariser.java:190:
> > warning: [SynchronizeOnNonFinalField] Synchronizing on non-final fields
> is
> > not safe: if the field is ever updated, different threads may end up
> > locking on different objects.
> > [javac] synchronized (myTotals) {
> > [javac]  ^
> > [javac] (see
> > http://errorprone.info/bugpattern/SynchronizeOnNonFinalField)
> >
>
> False positive for me in this case but others review is welcome.
>
> >
> > 1 error [ChainingConstructorIgnoresParameter] The called constructor
> > accepts a parameter with the same name and type as one of its caller's
> > parameters, but its caller doesn't pass that parameter to it.  It's
> likely
> > that it was intended to.
> > http://errorprone.info/bugpattern/ChainingConstructorIgnoresParameter
> >
> > [javac]
> > C:\Util\0_perso\TestError\trunk\src\core\org\apache\
> > jmeter\gui\util\FilePanel.java:44:
> > error: [ChainingConstructorIgnoresParameter] The called constructor
> > accepts
> > a parameter with the same name and type as one of its caller's
> parameters,
> > but its caller doesn't pass that parameter to it.  It's likely that it
> was
> > intended to.
> > [javac] this(title, (String) null, false);
> > [javac] ^
> > [javac] (see
> > http://errorprone.info/bugpattern/ChainingConstructorIgnoresParameter)
> > [javac]   Did you mean 'this(title, filetype, false);'?
> >
>
> Good catch.
> It affected Html Assertion and IncludeController
>
> >
> >
> > Anybody have already use this tool and check if results ara false
> positive?
> >
>
> Seems to be a good bug detector.
>
> >
> > 

How should no-op setter methods be filed in Bugzilla?

[Epp, Jeremiah W (Contractor)]

While working on our load automation tooling, I've had to figure out a lot
of obscure and relatively undocumented things about the JMeter internals.
One of the more bizarre things I've run into is a bunch of setter methods
that apparently just don't work, forcing you to use setProperty() in a bunch
of places instead.  It's really annoying.

Example:
JSR223PostProcessor jsr = new JSR223PostProcessor();
jsr. setScriptLanguage("beanshell");   // This doesn't actually do anything.
jsr. setProperty("scriptLanguage", "beanshell"); // We have to use this.

I realised last Friday (after hitting two more) that I should probably be
reporting these, but I wanted to check on the list first about how we want
them in Bugzilla.  Should each method have a bug?  Each class?  Should there
be a tracking bug for them?  A bz Keyword?  Please advise.

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.

JDK 9 & JDK 9 with Project Jigsaw b144 are available on java.net

[Rory O'Donnell]

Hi Philippe,

Early Access b144  (#5709) for JDK 9 with 
Project Jigsaw is available on java.net, summary of changes are listed 
here. 



Early Access b144  for JDK 9 is 
available on java.net, summary of  changes are listed here 
.


There have been a number of fixes to bugs reported by Open Source 
projects since the last availability email  :


 * JDK-8156149 : Blurry rendering on Windows 7 at 125% screen setting
 * JDK-8167431 : tools javac takes too long time to resolve interface
   dependency
 * JDK-8062810 : infrastructure Examine src.zip in JDK image and decide
   if source classes should be organized by module

*Proposal* - latest update

 *b142 of JDK 9 with project Jigsaw has the initial implementation
   of open modules and open packages as detailed in the recent proposal
   for #ReflectiveAccessToNonExportedTypes [1]

*Tool*

Adapted from JEP 277 [2]

 * A static analysis tool jdeprscan has been provided that scans a jar
   file (or some other aggregation of class files) for uses of
   deprecated API elements.

*Schedule*

 * The proposed JDK 9 schedule has been adopted and posted on the Open
   JDK 9 Project Page [3]


Rgds,Rory

[1] 
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html

[2] http://openjdk.java.net/jeps/277
[3] http://openjdk.java.net/projects/jdk9/

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

Re: [VOTE] Release JMeter 3.1 RC3

[Felix Schumacher]

Am 13. November 2016 20:34:16 MEZ, schrieb Milamber :
>Hello,
>
>The third release candidate for JMeter 3.1 (r1769531) has been
>prepared, 
>and your votes are solicited.
>
>This release brings new features and fixes bugs.
>
>Please, test this release candidate (with load tests and/or functional 
>tests) using Java 7/8 on Linux/Windows/Mac OS, especially on the 
>changes. The feedback are welcome.
>
>You can read the New and Noteworthy section with some screenshots to 
>illustrate improvements and full list of changes at:
>http://home.apache.org/~milamber/jmeter-3.1RC3/docs/changes.html
>
>JMeter is a Java desktop application designed to load test functional 
>behavior and measure performance. The current version is targeted at 
>Java 7+.
>
>Download - Archives/hashes/sigs:
>
>https://dist.apache.org/repos/dist/dev/jmeter/v3.1_RC3/
>(dist revision r16985)
>
>RAT report:
>
>http://home.apache.org/~milamber/jmeter-3.1RC3/dist/rat-report-jmeter-3.1RC3.txt
>
>MD5 hashes of archives for this vote:
>
>37e3c75cf80d2c60444e429bb0c27ae6 *apache-jmeter-3.1.tgz
>f096f4991454a22850ec6174331cfeed *apache-jmeter-3.1.zip
>a3e308d541a6c077ec322bce0d699a77 *apache-jmeter-3.1_src.tgz
>96b94f4e0189bd0aa6e578e80323e6b7 *apache-jmeter-3.1_src.zip
>
>Site Docs are here:
>http://home.apache.org/~milamber/jmeter-3.1RC3/docs/
>
>Maven staging repository is accessible here:
>https://repository.apache.org/content/repositories/orgapachejmeter-1013/org/apache/jmeter/
>
>Tag:
>https://svn.apache.org/repos/asf/jmeter/tags/v3_1_RC3/
>
>Keys are here:
>https://www.apache.org/dist/jmeter/KEYS
>
>N.B.
>To download the dependencies: "ant download_jars"
>
>To create the jars and test JMeter: "ant package test".
>
>JMeter 3.1 requires Java 7 or later to run.
>
>Some known issues and incompatible changes are listed on changes page.
>http://home.apache.org/~milamber/jmeter-3.1RC3/docs/changes.html#Known%20problems%20and%20workarounds
>
>
>All feedback and vote are welcome.
>   
>[x] +1  I support this release
>[  ] +0  I am OK with this release
>[  ] -0   OK, but
>[  ] -1   I do not support this release (please indicate why)
>
>The vote will remain open for at least 72 hours.
>
>The PMC members please indicate the mention "(binding)" with your vote.

+1

Regards,
  Felix (binding)

>
>
>Note: If the vote passes, the intention is to release the archive files
>and rename the RC tag as the release tag.
>
>Thanks in advance!
>
>Milamber

Re: [VOTE] Release JMeter 3.1 RC3

[Vladimir Sitnikov]

> The third release candidate for JMeter 3.1 (r1769531) has been
> prepared, and your votes are solicited.

+1

Changelog looks good. I've downloaded and checked apache-jmeter-3.1.tgz. It
works on macOS 10.12.

ant download_jars & ant works from a git clone.

Vladimir