Re: [REPORT] Apache JMeter

[Rainer Jung]

On 13.11.2011 19:19, sebb wrote:

Proposed first board report:

If there are any additions, please reply ASAP.

Thanks!


The report looks good to me.

Thanks!

Rainer

Re: [REPORT-RFC] December report

[Rainer Jung]

+1

Rainer

Re: Release time ?

[Rainer Jung]

On 01.12.2011 22:57, Philippe Mouawad wrote:

Hello Sebb,
Don't you think we could make a release ?

Lots of important fixes have been made and 2 months have passed since last
release.


First of all congrats to the huge progress you are making.

What about BZ52189: "JMeter 2.5.1 slower than 2.4 for HTTP POST requests"

Is that problem reproducible and really in the range described in the 
first comment, or was that due to comparing different http samplers?


A drop in throughput from 130 to 80 just because of a newer version 
would be pretty serious IMHO. Unfortunately I didn't yet have the cycles 
to try it myself, but wanted to provide a heads up.


Regards,

Rainer

Re: Release time ?

[Rainer Jung]

On 04.12.2011 20:54, Philippe Mouawad wrote:

 From my tests, I don't have such a drop in performances (max 2%).
I also don't notice degradation on POST particularly.
I agree with Sebb, issue are in 2.5 and 2.5.1 so we won't degrade things in
a future 2.5.2.


I did a simple test using a very small file (2 bytes) to mostly check 
per request overhead. I let it run with 10 threads for a total of 
200.000 samples and only took the last 20.000 samples to calculate results.


Configuration was default, JVM was 1.6.0_29, System was Solaris Sparc 
with 2 CPUs for JMeter and Apache on a separate one CPU system.


CPU was not saturated, bandwidth neither.

Those tests showed:

- results for HttpClient3.1 and HttpClient4 are about the same
- results for JMeter 2.4, 2.5.1 and 2.5.2-dev are about the same
- response times measured with HttpClient are between 52% and 59% of the 
old Java Sampler
- wallclock time needed for the 20.000 samples was only 0.3% to 2.2% 
bigger than the sum of the response times, so overhead is minimal
- overhead, though minimal was about 2% for HttpClient and about 0.5 for 
the old Java sampler. Overall it is a big difference, but both numbers 
are pretty small.
- since overhead is small, throughput in requests per second behaves 
roughly like average response time, namely about 740 requests per second 
for HttpClient and about 400-440 for the old Java sampler. So throughput 
is about 70% better for the newer samplers.
- CPU was higher for HttpClient, but only about 50-60%, so relative to 
throughput (per request) it was a bit lower.


"about the same" means differences were smaller than variability of test 
runs, always less than 10%.


It could be, that the test results will be very different, for bigger 
response sizes, KeepAlive turned off, real live tests with cookies etc. etc.


At least the base line looks good and I don't see a relevant difference 
between 2.4 and 2.5.x.


Regards,

Rainer


On Sun, Dec 4, 2011 at 5:27 PM, sebb  wrote:


On 4 December 2011 16:09, Rainer Jung  wrote:

On 01.12.2011 22:57, Philippe Mouawad wrote:


Hello Sebb,
Don't you think we could make a release ?

Lots of important fixes have been made and 2 months have passed since

last

release.



First of all congrats to the huge progress you are making.

What about BZ52189: "JMeter 2.5.1 slower than 2.4 for HTTP POST requests"

Is that problem reproducible and really in the range described in the

first

comment, or was that due to comparing different http samplers?


Not sure; I've not been able to reproduce it yet, and the data so far
does not give much clue as to what is happening.


A drop in throughput from 130 to 80 just because of a newer version

would be

pretty serious IMHO. Unfortunately I didn't yet have the cycles to try it
myself, but wanted to provide a heads up.


Agreed; however if the problem is difficult to solve I see no harm in
releasing another version so long as it is no worse than 2.5.1, and so
long as the problem is eventually resolved.


Regards,

Rainer

Re: Translation

[Rainer Jung]

On 11.12.2011 22:06, Philippe Mouawad wrote:

Hello Sebb, Milamber, Rainer, all,
What do you think of sending a message on jmeter user list for translation
request ?
We now have all missing labels in all languages computed automatically by
PackageTest in resources.
Maybe we could have some volunteers for translation ?


+1

I might have a bit of time late during the week for some german 
translations or at least to do some qa in case we already received some 
new ones during the week.


Regards,

Rainer

Time for a release?

[Rainer Jung]

Hello everyone,

at the beginning of December 2011 we discussed, whether we should have a 
release soon. I think the overall opinion was "yes" but it seems the 
project is still busy with fixing things and adding enhancements. 
Nevertheless I have the impression there are now enough changes to 
warrant the next release and get all the nice new stuff out in users 
hands. I don't know whether it should be a 2.5.2 or 2.6 though.


Kudos to all the effort you put into JMeter!

Regards,

Rainer

Re: svn commit: r1234186 - /jmeter/trunk/xdocs/stylesheets/project.xml

[Rainer Jung]

On 20.01.2012 23:22, Philippe Mouawad wrote:

Hello Sebb, Milamber,Rainer,
I added 2 links at root of index to Component Reference and Functions
Reference.

This is a proposition, I personnaly always search for these for a while
before finding them , and in my opinion they are very useful .


I like it although the source indentation of that file is a bit weird, 
so at first sight gives wrong impression of the nesting of menu items.


Thanks,

Rainer

Re: Time for a release?

[Rainer Jung]

On 21.01.2012 17:42, sebb wrote:

I also want to add a signing target which can loop through all the
dist artifacts (archives, poms, jars).

That will need GPG installed, preferably GPG 2.x


Note that Mark has added this feature to the Tomcat ant build just very 
recently. You can have a look.


Regards,

Rainer

Re: [VOTE] Release JMeter 2.6 RC2

[Rainer Jung]

On 29.01.2012 17:36, Milamber wrote:

Hello,

The second release candidate for JMeter 2.6 has been prepared, and your
votes are solicited.

This release brings some valuable improvements and fixes some bugs.

If you can,  some tests of this release candidate (load tests and/or
functional tests) with JVM 5/6/7 on Linux/Windows/Mac OS on changes are
welcome.

New and Noteworthy with some screenshots to illustrate improvements and
list of changes:
http://people.apache.org/~milamber/jmeter-2.6RC2/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 1.5+.

Archives/hashes/sigs and RAT report:

http://people.apache.org/~milamber/jmeter-2.6RC2/dist

MD5 hashes of archives for this vote:

87c13f4e1b32b5ec5f2a77426d624b4d *apache-jmeter-2.6.tgz
21bf3f7a215b0cb450a3be828cdd9190 *apache-jmeter-2.6.zip
175932a8d35e91cea20f5f8039eae1b7 *apache-jmeter-2.6_src.tgz
fa0f0dec9004a3d48c48e28183251831 *apache-jmeter-2.6_src.zip

Site Docs are here:
http://people.apache.org/~milamber/jmeter-2.6RC2/docs/

Maven staging repo is accessible here:
https://repository.apache.org/content/repositories/orgapachejmeter-161/org/apache/jmeter/

Tag:
http://svn.apache.org/repos/asf/jmeter/tags/v2_6_RC2 (r1237316)

Keys are here:
http://svn.apache.org/repos/asf/jmeter/dist/
also
http://people.apache.org/~milamber/

N.B.
To download the dependencies: "ant download_jars"

To create the jars and test JMeter: "ant package test".

JMeter 2.6 requires Java 1.5 or later.

Note that there is a bug in Java on some Linux systems that manifests
itself as the following error when running the test cases or JMeter itself:

  [java] WARNING: Couldn't flush user prefs:
  java.util.prefs.BackingStoreException:
  java.lang.IllegalArgumentException: Not supported: indent-number

This does not affect JMeter operation.


All feedback (and votes!) welcome.

[+1] +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)


+1 for release.

Please check the following details. Though I could not find a real 
problem, I'm not totally sure, that there is no problematic observation. 
It is the first JMeter release I checked a bit more thoroughly. Thanks 
for RM!


Details:

- MD5 OK
- signatures OK
- key in KEYS file
- AFAIK the key is not in the web of trust. It would be good
  if we found a way to sign your key.
- gz and zip for src and bin consistent
- src consistent with svn tag, except for the following points:

Only in gz/bin/testfiles: Sample_Chart.png
Only in gz/bin/testfiles: Sample_Line_Graph.png
Only in svn: doap_JMeter.rdf
Only in svn: docs
Only in svn/lib: api
Only in svn/lib: doc
Only in svn/lib: ext
Only in svn/lib: junit
Only in svn: rat-excludes.txt
Only in svn: STATUS

- extras/proxycert.sh in bin distributable not executable
- *.sh files in svn and src distribution not executable
- bin/jmeter and bin/jmeter-.server files in src distribution not 
executable (but they are in svn)
- xdocs/download_jmeter.cgi file in src distribution not executable (but 
it is in svn)


- builds fine

But: I had to set -Ddisable-check-versions=true to build from the src 
tgz. Setting -Ddisable-svnCheck=true was not sufficient, it demanded for 
svn.revision and setting that seemed to change the version numbers.


- build result looks consistent with distribution, except for
  - timestamps in generated javadoc
  - binary jar files
  - Yen sign in line 3348 of file printable_docs/usermanual/functions.html

- one Javadoc warning:

src/jorphan/org/apache/jorphan/test/UnitTestManager.java:31: warning - 
Tag @see: reference not found: org.apache.jorphan.test.AllTests


- ran the tests (but only with java.awt.headless)

- I have not checked the staging repository.

Build and tests were done using Java 1.5.0_22, OS was Solaris 10 Sparc,

Regards,

Rainer

Re: [VOTE] Release JMeter 2.6 RC2

[Rainer Jung]

On 31.01.2012 00:48, sebb wrote:

On 30 January 2012 22:24, Rainer Jung  wrote:

Please check the following details. Though I could not find a real problem,
I'm not totally sure, that there is no problematic observation. It is the
first JMeter release I checked a bit more thoroughly. Thanks for RM!

Details:

- MD5 OK
- signatures OK
- key in KEYS file
- AFAIK the key is not in the web of trust. It would be good
  if we found a way to sign your key.
- gz and zip for src and bin consistent
- src consistent with svn tag, except for the following points:

Only in gz/bin/testfiles: Sample_Chart.png
Only in gz/bin/testfiles: Sample_Line_Graph.png


Those are test output files; should probably be excluded in future.
Or they should get created elsewhere.


OK


Only in svn: doap_JMeter.rdf


That's normal for many projects.
Possibly should find somewhere else to keep the doap - it's only
really useful for the projects.a.o site as it gets updated after the
release.


OK


Only in svn: docs


Yes, those are the site docs.


OK


Only in svn/lib: api
Only in svn/lib: doc
Only in svn/lib: ext
Only in svn/lib: junit


They are empty directories which don't get added to archives - not
sure if all archive types support directory entries


me neither.


Only in svn: rat-excludes.txt


That's only used by buildbot.


OK


Only in svn: STATUS


Only really relevant to SVN checkouts.


OK

I will exclude all of the above from checking for future versions.


- extras/proxycert.sh in bin distributable not executable
- *.sh files in svn and src distribution not executable
- bin/jmeter and bin/jmeter-.server files in src distribution not executable
(but they are in svn)
- xdocs/download_jmeter.cgi file in src distribution not executable (but it
is in svn)


These items should be fixed, but are readily fixable by end users so I
don't think are blocking.


ACK


- builds fine

But: I had to set -Ddisable-check-versions=true to build from the src tgz.
Setting -Ddisable-svnCheck=true was not sufficient, it demanded for
svn.revision and setting that seemed to change the version numbers.


What command did you use to build?


ant distribution -Djmeter.version=2.6 -Djava.awt.headless=true

First added -Ddisable-svnCheck=true because I wasn't building from an 
svn workspace, then added -Ddisable-check-versions=true because the 
build was still complaining about the missing svn.revision property and 
setting that property didn't seem to produce the right thing either.



"ant package" is the normal developer build; "ant distribution" is
mainly intended for use by RMs.
Probably need to document this better.


Ah, OK, thanks for the info.


- build result looks consistent with distribution, except for
  - timestamps in generated javadoc
  - binary jar files
  - Yen sign in line 3348 of file printable_docs/usermanual/functions.html


That seems to be a feature of the build environment - works OK when I
generate that file on Windows.
I guess the build file may need tweaking to set the encoding.


It looks like you already fixed it (didn't test it though).


- one Javadoc warning:

src/jorphan/org/apache/jorphan/test/UnitTestManager.java:31: warning - Tag
@see: reference not found: org.apache.jorphan.test.AllTests


Needs to be fixed, but not a blocker.


ACK


- ran the tests (but only with java.awt.headless)

- I have not checked the staging repository.

Build and tests were done using Java 1.5.0_22, OS was Solaris 10 Sparc,


Thanks for the thorough checks and feedback!


Regards,

Rainer

Re: Commit issue

[Rainer Jung]

On 05.02.2012 01:35, sebb wrote:

On 4 February 2012 23:57, Philippe Mouawad  wrote:

Maybe getting this issue:
http://www.apache.org/dev/version-control.html

"specified baseline is not the latest baseline" errors

If you're getting an error message like the following:

svn: Commit failed (details follow):
svn: The specified baseline is not the latest baseline, so it may not be
checked out.

This may be because of a short lag in the synchronization between
Subversion mirrors, and can occur if multiple commits are run immediately
after each other. This error will usually only happen if you are located in
Europe, or explicitly using the European mirror.

Waiting for 10 seconds and repeating the command should succeed.



I've never had that problem, and I use the EU mirror.

I think it mainly applies to multiple commits in sequence, as are
sometimes generated by Maven.


I sometimes do experience a similar problem, e.g. when trying to do "svn 
up" directly after a commit (not sure about the exact error message). 
That one definitely has to do with the sync lag. If I wait a few 
seconds, then "svn up" succceeds.


Rainer

Re: Moving to Java 1.6 for a future JMeter release?

[Rainer Jung]

On 26.02.2012 01:33, sebb wrote:

JMeter currently targets Java 1.5 (but will of course run on Java 1.6+).

At some point it might be useful to require Java 1.6 as the minimum
version, as it does offer some useful enhancements.

Would requiring Java 1.6 cause a problem for any JMeter users?

It seems unlikely, as JMeter should be run on a different host from
the system under test; i.e. the change won't require a change to
existing applications.

But if there are good reasons why JMeter should stick with Java 1.5
rather than moving to Java 1.6, please let us know.


+1 for 1.6.

Rainer

Re: Release a 4.0 (second try)

[Rainer Jung]

Hi Philippe,

Am 10.12.2017 um 11:03 schrieb Philippe Mouawad:

Thanks but screenshot is still unreadable for me.


I think that's just the resolution shown on that web site. When I look 
at it, it shows a little plus sign and clicking on the image it enlarges 
it. I can click multiple times until it looks readable, so the image 
resolution is good.


Regards,

Rainer


On Sunday, December 10, 2017, jmeter tea  wrote:


Add new image:
https://imgur.com/t35J8c3
I selected a disable element and it can't be seen

OS: Windows 7
Screen Resolution: 1920 x 1080
Java: 8

On Sun, Dec 10, 2017 at 11:56 AM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:


Hi,
The screenshot is bot very clear.
Can you make it bigger and highlight what is bad ?

Also what are you using :
- OS
- Screen definition
- Java version

Thank you

On Sunday, December 10, 2017, jmeter tea  wrote:


The disable/enable color are very similar and hard to distinguish

between

them.
IMHO make enable element more whiter
Also when moving from Nimbus to Dracula the disabled elements can't be
seen. see https://imgur.com/37stPt9

On Sun, Dec 10, 2017 at 11:07 AM, Philippe Mouawad <
p.moua...@ubik-ingenierie.com> wrote:


Hello,
I think we have now a stable version , I am not aware of any

remaining

issue on nightly.

So I propose that we release a new version before end of year.

Thoughts ?

Regards
Philippe M.
@philmdot






--
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.2 RC4

[Rainer Jung]

Am 23.10.2019 um 17:21 schrieb Vladimir Sitnikov:

I looked into the gradle build scripts, but didn't find the place where
the checksums are generated


It is here:
https://github.com/vlsi/vlsi-release-plugins/blob/73b67142a10ff3bcedc136d1a99e3d9f3a827a2e/plugins/stage-vote-release-plugin/src/main/kotlin/com/github/vlsi/gradle/release/ReleaseArtifacts.kt#L75


If I understand it correctly, one could add something like

  "format" to "MD5SUM",

or more explicitly

  "pattern" to "{0} *{1}",

since these are supported by the original ant checksum task.

Regards,

Rainer

Re: Time for a release ?

[Rainer Jung]

On 10.05.2012 19:45, Philippe Mouawad wrote:

Hello Sebb, Milamber, Rainer,
3 months have passed since last release and Many fixes and Enhancements
have been implemented:`

- 37 Bugs fixed
- 25 enhancements implemented

What about a release before starting major Enhancements Like parallel
requests or database save service ?
I don't see in progress bugs except for these 2 but they can wait I think:

- 53168
- 52131



+1 for starting the release process.

Regards,

Rainer

Re: [VOTE] Release JMeter 2.7 RC1

[Rainer Jung]

On 19.05.2012 19:11, Milamber wrote:

[ 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)


+1 for release.

Some minor observations, roughly the same as last time plus some other 
details for the yen sign problem, small new problems for collapse.png 
and expand.png and some "2.6" string in a subversion file which was 
fixed in the distribution file.


Thanks for RM!

Details:

- MD5 OK
- signatures OK
- key in KEYS file
- AFAIK the key is still not in the web of trust. It would be good
  if we found a way to sign your key.
  Maybe during ApacheCon EU in November?
- gz and zip for src and bin consistent apart from:
  - Files extras/collapse.png and extras/expand.png differ
(the ones in the zip are bigger, gz and svn look the same,
 I guess some unintended conversion happened).
Those files are not part of the distribution if I build it myself.
Not a blocker, should be fixed before next time.
  - File printable_docs/usermanual/functions.html again the yen sign
in line 3531. File says it is ISO-8859-1 encoded, File in gz
looks OK (and like the docs one in svn), file in zip has
a multibyte character instead of decimal 165. When I rebuild JMeter
myself, the yen sign looks right in both files, so seems the
be an issue with build environment or process.
Not a blocker.

- src consistent with svn tag, except for the following points:

  - File xdocs/overview.html contains "2.6" in svn but "2.7" in 
distribution archives


  Only in svn/extras: collapse.png
  Only in svn/extras: expand.png

  Already observed for 2.6
  (and I won't mention them for the next release):

  Only in gz/bin/testfiles: Sample_Chart.png
  Only in gz/bin/testfiles: Sample_Line_Graph.png
  Quoting sebb said: Those are test output files; should probably be 
excluded in future. Or they should get created elsewhere.


  Only in svn: doap_JMeter.rdf
  Quoting sebb: That's normal for many projects.
Possibly should find somewhere else to keep the doap - it's only
really useful for the projects.a.o site as it gets updated after the
release.

  Only in svn: rat-excludes.txt
  Quoting sebb: That's only used by buildbot.

- File permissions in svn and src distribution (OK in bin distribution)

  - extras/proxycert.sh and bin/*.sh files not executable
in svn and src distribution
  - bin/jmeter, bin/jmeter-server and xdocs/download_jmeter.cgi
files not executable in src distribution (but they are in svn)

- builds fine

- build result looks consistent with distribution, except for
  - timestamps in generated javadoc (expected)
  - binary jar files (expected)
  - yen sign in printable_docs/usermanual/functions.html OK now in
my own build (wasn't in 2.6)
  - missing /extras/collapse.png and extras/expand.png (see above)

- no Javadoc warnings

- ran the tests (but only with java.awt.headless)

- I have not checked the staging repository.

Build and tests were done using Java 1.5.0_22, OS was Solaris 10 Sparc,

Regards,

Rainer

Re: [VOTE] Release JMeter 2.7 RC1

[Rainer Jung]

Hi Milamber,


NB. I'm living in Morocco


That gives me nostalgic feelings. I went to Morocco when I was 19 and I 
really liked what I saw (no, this is not about drugs). It was nearly 30 
years ago and sure a lot will have changed. Do you live in one of the 
well-known towns (Casablanca, Marrakesh, Tanger, Rabat, Fes, ...)?


It would be really cool if you could make it to the EU conference, 
although this year it is located in a small German town, so it is more 
about people than the location. There is a travel assistance committee 
(TAC) at ASF which can help funding your travel, although they might 
want some help for the conference in exchange.


Finally: congratulations to what happened in north africa the last 2 
years. I know Maroc is somewhat different, but I went to egypt last year 
in April and was very impressed by the people and the athmosphere there.


Have a nice week!

Rainer

Re: [VOTE] Release JMeter 2.7 RC1

[Rainer Jung]

Sorry for the noise, my last mail was meant to be sent to Milamber direct.

Rainer

ApacheCon 2012 Was: [VOTE] Release JMeter 2.7 RC1

[Rainer Jung]

Hi Philippe,

On 21.05.2012 21:48, Philippe Mouawad wrote:

Hello,
Rainer, in which German Town will ApacheCon occur ?


Sinsheim, close to Heidelberg / Mannheim.

As Milamber wrote some info is at: http://www.apachecon.com/

Map:

http://maps.google.de/maps?q=Rhein-Neckar+Arena,+Sinsheim&hl=de&sll=50.72764,7.0752&sspn=0.036891,0.090895&oq=sinsheim+arena&t=h&hq=Rhein-Neckar+Arena,+Sinsheim&z=15


Milamber, I live in North of France near Lille (Chti :-) ) (Wilkommen bei
den Chti's for Rainer :-) ),


Less than 4 hours to where I live (close to Cologne)


rarely going to Paris but could be an occasion
but not for signing Key as I don't know the process, Rainer what is it
exactly ?


It is simple. You prepare your key in advance and keep it in a well 
secured place. You bring your key fingerprint with you. The key itself 
should not be moved to an insecure environment.


Then during the conference there's a key signing party where

- everoyne gets a list of the key fingerprints of the keys to sign and 
the names of the owners


- all key owners are asked, whether their key fingerprint is ok

- the other people check your identity and later will sign your key.

The event itself will be announced during the conference as "key 
signing" and then you can send an email containing your key fingerprint 
to the organizer of the key signing, who compiles a list of them and 
print hard copies for the event.


For reference:

http://www.apache.org/dev/openpgp.html

http://www.apache.org/dev/release-signing.html

Regards,

Rainer

Re: [VOTE] Release JMeter 2.7 RC3

[Rainer Jung]

On 24.05.2012 22:10, Milamber wrote:

[ 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)


+1 for release, thanks for RM!

All minor packaging regressions I observed in RC1 are fixed.

Details:

- MD5 OK
- signatures OK
- key in KEYS file
- AFAIK the key is still not in the web of trust.

- gz and zip for src and bin consistent

- src consistent with svn tag, except for expected differences

- builds fine

- build result looks consistent with distribution, except for
  - timestamps in generated javadoc (expected)
  - binary jar files (expected)

- no Javadoc warnings

- ran the tests (but only with java.awt.headless)

- I have not checked the staging repository.

Build and tests were done using Java 1.5.0_22, OS was Solaris 10 Sparc,

Regards,

Rainer

Re: [VOTE] Release JMeter 2.8 RC1

[Rainer Jung]

On 30.09.2012 12:39, Milamber wrote:

[XX] +1  I support this release


+1 for release, thanks for RM!

Details:

- MD5 OK
- signatures OK
- key in KEYS file

- gz and zip for src and bin consistent except for:
  - heapdump.cmd and heapdump.sh in bin directory of svn,
missing from gz and zip binary releases
  - heapdump.sh in src gz, neither heapdump.sh
nor heapdump.cmd in src zip

- builds fine

- build result looks consistent with distribution, except for
  - timestamps in generated javadoc (expected)
  - binary jar files (expected)
  - heapdump.sh

- no Javadoc warnings

- ran the tests (but only with java.awt.headless)

- I have not checked the staging repository.

Build and tests were done using Java 1.5.0_22, OS was Solaris 10 Sparc.

Regards,

Rainer

Re: [VOTE] Release JMeter 2.8 RC2

[Rainer Jung]

On 03.10.2012 00:08, Milamber wrote:

[XX] +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)


+1 for release, thanks for RM!

Details:

- MD5 OK
- signatures OK
- key in KEYS file

- gz and zip for src and bin consistent,
  heapdump script problem fixed.

- builds fine

- build result looks consistent with distribution, except for
  - timestamps in generated javadoc (expected)
  - binary jar files (expected)

- no Javadoc warnings

- ran the tests (but only with java.awt.headless)

- I have not checked the staging repository.

Build and tests were done using Java 1.5.0_22, OS was Solaris 10 Sparc.

Regards,

Rainer

Syncing command line properties for remote testing

[Rainer Jung]

Hi,

I ran into the problem, that JMeter properties set during startup via 
command line (-J) are not available during remote testing. It seems this 
is well known, because it is mentioned on


http://wiki.apache.org/jmeter/JMeterRemoteTestingEnhancements

More precisely you can't set the properties for the remote instances 
from the GUI one. It would be nice, if the GUI could push them or the 
remote instances could pull them before starting a test.


Does anyone have an idea whether that would be hard to implement?

Regards,

Rainer

Re: Syncing command line properties for remote testing

[Rainer Jung]

On 07.10.2012 18:35, Shmuel Krakower wrote:

Hi
I have not tried that but doesn't -G works for you?


Thanks for the hint, I had overlooked that one. Will try tomorrow.

Regards,

Rainer


בתאריך 2012 10 7 18:39, מאת "Rainer Jung" :


Hi,

I ran into the problem, that JMeter properties set during startup via
command line (-J) are not available during remote testing. It seems this is
well known, because it is mentioned on

http://wiki.apache.org/jmeter/**JMeterRemoteTestingEnhancement**s<http://wiki.apache.org/jmeter/JMeterRemoteTestingEnhancements>

More precisely you can't set the properties for the remote instances from
the GUI one. It would be nice, if the GUI could push them or the remote
instances could pull them before starting a test.

Does anyone have an idea whether that would be hard to implement?

Regards,

Rainer

Support "language" in user.properties?

[Rainer Jung]

Currently the language property is not supported in user.properties, 
because the locale gets initialized before user.properties is read. I 
guess that's because the logging is then also started and localization 
support is needed.


Nevertheless it seems to work well to switch locale later after 
user.properties and command line flags have been read. I tested the 
following patch:


Index: src/core/org/apache/jmeter/JMeter.java
===
--- src/core/org/apache/jmeter/JMeter.java  (revision 1398057)
+++ src/core/org/apache/jmeter/JMeter.java  (working copy)
@@ -679,6 +679,9 @@
 remoteProps.put(SampleEvent.SAMPLE_VARIABLES, 
sample_variables);

 }
 jmeterProps.put("jmeter.version", JMeterUtils.getJMeterVersion());
+// Initialize locale again in case it was overwritten by
+// user.properties or command line flags
+JMeterUtils.initLocale();
 }

 /*


WDYT?

Regards,

Rainer

Re: [VOTE] Release JMeter 2.9 RC3

[Rainer Jung]

On 24.01.2013 17:54, Milamber wrote:
> All feedback (and votes!) welcome.
> 
> [XX] +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)

+1 for release, thanks for RM!

Details:

- MD5 OK
- signatures OK
- key in KEYS file

- gz and zip for src and bin consistent, except
  - LICENSE contains a new line ("Hedley"), with the special
copyright character. That is encoded differently in gz and
zip file. Could be OK, but probably better in future using "(C)"
like in the other lines
  - changes.xml contains a special character at the start of all 
items (square bullet #149), which lead to differently encoded chars
at that position in changes.html for gz and zip. Previous JMeter
version changes did not include any bullets in the h4 tag.
  Both are no big issues if issues at all.

- builds fine

- build result looks consistent with distribution, except for
  - timestamps in generated javadoc (expected)
  - binary jar files (expected)

- no Javadoc warnings

- ran the tests (but only with java.awt.headless)

- I have not checked the staging repository.

Build and tests were done using Java 1.6.0_37, OS was Solaris 10 Sparc.

Regards,

Rainer

Re: [VOTE] Release JMeter 2.9 RC3

[Rainer Jung]

On 28.01.2013 02:51, sebb wrote:
> On 27 January 2013 22:13, Milamber  wrote:
>> To do this, I suppose, I must change the svnmucc script (updatesite.txt)?
>> 
>> rm
>> https://svn.apache.org/repos/asf/jmeter/site
>>
>> cp
>> HEAD
>> https://svn.apache.org/repos/asf/jmeter/branches/docs-2.9/docs
>> https://svn.apache.org/repos/asf/jmeter/site
>> 
>>
>> by
>> 
>> rm
>> https://svn.apache.org/repos/asf/jmeter/site
>>
>> cp
>> HEAD
>> https://svn.apache.org/repos/asf/jmeter/trunk/docs
>> https://svn.apache.org/repos/asf/jmeter/site
>> 
>>
> 
> No, we don't copy site from trunk
> 
> Normally bugs are found in the docs some while after release, by which
> time trunk docs has moved on, possibly incompatibly.
> 
> So the idea was that branches/docs-m.n/docs should be copied from
> trunk at release, and then changes for the website get made to the
> branches copy (and to trunk if appropriate).

Just in case it wasn't clear: the site in svn is just an svn tree as
everything else. AFAIK svnmucc is only used to populate it from the
branch docs in a simple way.

So if there is a need to adjust specific site pages, you could also
check out the site, edit the page and commit.

If you want to keep the site consistent with the branch - which is a
good idea - then you can either edit the branch, commit it and then
merge to site or instead of merge like above "rm" and "cp" the branch to
site.

At least that's what I got out of the above recipe.

Regards,

Rainer

Re: svn:auto-props

[Rainer Jung]

On 18.07.2013 00:20, sebb wrote:
> The SVN server is now using 1.8.
> 
> This supports svn:auto-props [1], i.e. we can set the svn:auto-props
> property, and the server will automatically apply the appropriate
> properties.
> 
> This might be quite useful, as it's easy to forget to set the
> properties when committing a new file.
> 
> Should we add it to the JMeter top-level directory?
> 
> JMeter uses quite a lot of different file extensions, and it may not
> be possible to list them all, but it might be worth adding at least
> the most common ones.
> 
> [1] 
> http://blogs.collab.net/subversion/the-road-to-repository-dictated-configuration-day-2-autoprops

I like it.

Note that it seems the clients need to support it. So even after adding
it we shouldn't immediately drop the auto props settings form our local
svn config unless we are sure our clients respect the svn:auto-props.

Regards,

Rainer

Re: svn commit: r1507418 - /jmeter/trunk/bin/jmeter

[Rainer Jung]

On 26.07.2013 22:06, pmoua...@apache.org wrote:
> Author: pmouawad
> Date: Fri Jul 26 20:06:10 2013
> New Revision: 1507418
> 
> URL: http://svn.apache.org/r1507418
> Log:
> Add a GC option for perm cleanup
> Add explanation on NEW zone
> 
> Modified:
> jmeter/trunk/bin/jmeter
> 
> Modified: jmeter/trunk/bin/jmeter
> URL: 
> http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter?rev=1507418&r1=1507417&r2=1507418&view=diff
> ==
> --- jmeter/trunk/bin/jmeter (original)
> +++ jmeter/trunk/bin/jmeter Fri Jul 26 20:06:10 2013
> @@ -45,7 +45,7 @@ HEAP="-Xms512m -Xmx512m"
>  
>  # There's an awful lot of per-sample objects allocated during test run, so we
>  # need a large eden to avoid too frequent scavenges -- you'll need to tune 
> this
> -# down proportionally if you reduce the HEAP values above:
> +# down proportionally if you modify the HEAP values above:
>  NEW="-XX:NewSize=128m -XX:MaxNewSize=128m"
>  
>  # This ratio and target have been proven OK in tests with a specially high
> @@ -75,7 +75,7 @@ TENURING="-XX:MaxTenuringThreshold=2"
>  RMIGC="-Dsun.rmi.dgc.client.gcInterval=60 
> -Dsun.rmi.dgc.server.gcInterval=60"
>  
>  # Increase MaxPermSize if you use a lot of Javascript in your Test Plan :
> -PERM="-XX:PermSize=64m -XX:MaxPermSize=128m"
> +PERM="-XX:PermSize=64m -XX:MaxPermSize=128m -XX:+CMSClassUnloadingEnabled"

Note that the switch wouldn't do anything by default, because it only is
effective is the user switches to CMS garbage collection
(-XX:+UseConcMarkSweepGC). If CMS is not used, class unloading is
default (boolean switch ClassUnloading). Fortunately the
CMSClassUnloadingEnabled switch is simply ignored if CMS is not used.

OTOH it also has a side effect: it will let the CMS check how much
memory in the perm gen is free to decide whether it should run. By
default it will run when perm is 92% filled. This can be changed with
the CMSInitiatingPermOccupancyFraction switch. It can not only run when
the perm gen is full, like he traditional compactifying GC, because it
is expected to run concurrently with the application, so there must be
some free space left to let the app run successfully until the CMS has
freed up garbage.

So as long as JMeter stays typically below 92% that's fine, but if it
frequently goes to 92%, e.g. because it always needs 91% and quickly
adds temporary classes which make up the last percent, that would result
in frequent CMS runs. This is something to keep in mind.

Should we provide a commented block of switch prepared for the CMS use?

Regards,

Rainer

Re: svn commit: r1507418 - /jmeter/trunk/bin/jmeter

[Rainer Jung]

On 27.07.2013 22:06, Philippe Mouawad wrote:
> Thanks Rainer for explanation.
> From your experience with GC would you say adding those 2 options is a good
> idea ?
> -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled

In general CMS produces shorter pauses but is a bit less efficient (more
overhead in terms of CPU). Since it doesn't stop the app during most of
its run, you'd also need a bit more tenured space. Finally it fragments
tenured and if a big object is promoted and there's no longer enough
consecutive free space, then once a non-CMS GC will kick in (with the
normal pause times), clean up and thus defragment everything as a side
effect. So even with CMS you might occasionally see a non-CMS GC running.

On a modern system, especially server type, the non-CMS GC runs on
multiple threads in parallel. Since our default heap size is "only" 0.5
GB, the pause times caused by GC should be acceptable. So I'd stay with
the non-CMS GC as the default setting.

But if one needs multi-GB heap then switching to CMS could make sense in
order to avoid multi-second pauses every now and then.

I suggest to add a commented CMS block using

-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+CMSClassUnloadingEnabled
-XX:+ExplicitGCInvokesConcurrent

(the last of the four switches lets System.gc() but also the Distributed
DGC triggered e.g. by RMI also run as CMS; without the switch those
would run as non-CMS).

Typically one would also like to tune:

-XX:ParallelGCThreads=N
(some N depending on hardware)
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=NN
   (some percentage NN depending on memory behavior)
-XX:CMSInitiatingPermOccupancyFraction=MM
   (some percentage MM depending on memory behavior)

but there's no general recommendation possible for values, so we should
just ignore these.


In addition I propose to set "DEBUG" to following switches for the GC log:

-verbose:gc
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-XX:+PrintHeapAtGC
-XX:+PrintTenuringDistribution
-XX:+PrintGCApplicationConcurrentTime
-XX:+PrintGCApplicationStoppedTime

The only real downside here is that PrintGCDateStamps was only
introduced in 1.6.0_04. But since DEBUG is not active by default and it
is unlikely someone needing to debug stuff has Java 6 before update 04
running I suggest to add the flag.

I don't know whether there will be a problem with a to long command line
when actually using the flags on one of the supported platforms.

Since Java 1.6.0_35 and 1.7.0_07 there's also a way to write the GC log
to a rotating log file:

-Xloggc:FILENAME
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=10
-XX:GCLogFileSize=1M

(example values). But that's to fresh to assume in general, and since
JMeter is not a server daemon it should be OK to write the GC stuff to
STDOUT by default. Otherwise we could simply add the single switch

-Xloggc:gc.log

which will always start a new gc log after JMeter start, overwriting the
previous log.

Regards,

Rainer

> If not then let's remove it, otherwise +1 for your proposition of commented
> block for CMS.
> 
> On Sat, Jul 27, 2013 at 8:17 PM, Rainer Jung wrote:
> 
>> On 26.07.2013 22:06, pmoua...@apache.org wrote:
>>> Author: pmouawad
>>> Date: Fri Jul 26 20:06:10 2013
>>> New Revision: 1507418
>>>
>>> URL: http://svn.apache.org/r1507418
>>> Log:
>>> Add a GC option for perm cleanup
>>> Add explanation on NEW zone
>>>
>>> Modified:
>>> jmeter/trunk/bin/jmeter
>>>
>>> Modified: jmeter/trunk/bin/jmeter
>>> URL:
>> http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter?rev=1507418&r1=1507417&r2=1507418&view=diff
>>>
>> ==
>>> --- jmeter/trunk/bin/jmeter (original)
>>> +++ jmeter/trunk/bin/jmeter Fri Jul 26 20:06:10 2013
>>> @@ -45,7 +45,7 @@ HEAP="-Xms512m -Xmx512m"
>>>
>>>  # There's an awful lot of per-sample objects allocated during test run,
>> so we
>>>  # need a large eden to avoid too frequent scavenges -- you'll need to
>> tune this
>>> -# down proportionally if you reduce the HEAP values above:
>>> +# down proportionally if you modify the HEAP values above:
>>>  NEW="-XX:NewSize=128m -XX:MaxNewSize=128m"
>>>
>>>  # This ratio and target have been proven OK in tests with a specially
>> high
>>> @@ -75,7 +75,7 @@ TENURING="-XX:MaxTenuringThreshold=2"
>>>  RMIGC="-Dsun.rmi.dgc.client.gcInterval=60
>> -Dsun.rmi.dgc.server.gcInterval=60"
>>>
>>>  # Increase MaxPermSize if you use a lot of Javascript in your Test Pla

Re: Contributing link for JMeter site

[Rainer Jung]

On 29.07.2013 12:41, sebb wrote:
> There's currently no obvious link as to how to contribute back to JMeter 
> itself.
> 
> The "Get Involved" link is a general link about getting involved in
> the ASF (so I have moved it under the ASF heading).
> 
> I think it would be useful to have a short page summarising the ways
> to contribute to JMeter itself. For details, it would link to other
> pages (where they exist - if not we might need to create some on the
> site or perhaps Wiki).
> 
> This summary would cover such things as
> - filing patches via Bugzilla
> - responding to mailing list questions
> - updating the Wiki
> - translations
> - enhancements to JMeter

Sounds good, I'd move mailing list discussion as the first topic bit
that's just a personal preference.

Didn't check, but do we describe somewhere else how to build JMeter from
svn?

> The idea is to provide an overview of the ways to contribute, without
> too many details that may clutter the page.

Excellent idea.

> ==
> 
> I think the link needs to be reasonably high up the LH menu
> Possibly we should move the Community section higher up and add it there.

It could at least replace the unspecific "Get Involved" link. Not sure
whether I would move the "Community" block further up, since for most
visitors of the site the menu items that are currently higher up should
be more important.

Regards,

Rainer

user.classpath, search_path and many jar files

[Rainer Jung]

I have a situation where the user.classpath contains many jar files
(about 100). Listing all of the jar files is tedious, difficult to
maintain and not in any place where one can configure user.classpath
possible or easy because of line length restrictions.

Looking at the code I saw that in some places jar files lying in
directories configured for class search are automatically also searched,
but sometimes not.

There are three cases:

- not auto-searching the jar files:

o.a.jmeter.JMeter start() calls updateClassLoader() calls updatePath()
for search_paths and user.classpath. updatePath() calls
NewDriver.addPath() for each path contained in those settings. Finally
NewDriver.addPath() adds them to the system property "java.class.path"
without listing all jar files contained in directories.

So the class loader itself does not know about such jar files.

- auto-searching such jar files in ClassFinder.findClassesThatExtend()
using search_paths for JMeter extension:

In findClassesThatExtend() a call to addJarsInPath() will automatically
add all jar files found in a configured directory.

- auto-searching jar files in user.classpath for JUnit setup:

In JUnitTestSamplerGui the user.classpath property is used to search for
classes extending Test or TestCase but the search is based on
ClassFinder, so will automatically search through jar files.

I propose to also add the jar files in the first case, the updatePath
setting up the class loader. I guess the only concern would be the speed
of class loading? IMHO if there are only few such jar files, then there
should be no problem and if there are many such jar files, then not
needing to configure them all is really helpful. So the remaining case
is if there are many jar files auto-detected which are not really
needed. That means it might make sense to make the behavior configurable
with default the old behavior.

Comments?

Regards,

Rainer

Re: user.classpath, search_path and many jar files

[Rainer Jung]

On 11.08.2013 21:45, Philippe Mouawad wrote:
> On Fri, Aug 9, 2013 at 9:45 PM, Rainer Jung  wrote:
> 
>> I have a situation where the user.classpath contains many jar files
>> (about 100). Listing all of the jar files is tedious, difficult to
>> maintain and not in any place where one can configure user.classpath
>> possible or easy because of line length restrictions.
>>
>> Looking at the code I saw that in some places jar files lying in
>> directories configured for class search are automatically also searched,
>> but sometimes not.
>>
>> There are three cases:
>>
>> - not auto-searching the jar files:
>>
>> o.a.jmeter.JMeter start() calls updateClassLoader() calls updatePath()
>> for search_paths and user.classpath. updatePath() calls
>> NewDriver.addPath() for each path contained in those settings. Finally
>> NewDriver.addPath() adds them to the system property "java.class.path"
>> without listing all jar files contained in directories.
>>
>> So the class loader itself does not know about such jar files.
>>
>> - auto-searching such jar files in ClassFinder.findClassesThatExtend()
>> using search_paths for JMeter extension:
>>
>> In findClassesThatExtend() a call to addJarsInPath() will automatically
>> add all jar files found in a configured directory.
>>
>> - auto-searching jar files in user.classpath for JUnit setup:
>>
>> In JUnitTestSamplerGui the user.classpath property is used to search for
>> classes extending Test or TestCase but the search is based on
>> ClassFinder, so will automatically search through jar files.
>>
>> I propose to also add the jar files in the first case, the updatePath
>> setting up the class loader. I guess the only concern would be the speed
>> of class loading? IMHO if there are only few such jar files, then there
>> should be no problem and if there are many such jar files, then not
>> needing to configure them all is really helpful. So the remaining case
>> is if there are many jar files auto-detected which are not really
>> needed. That means it might make sense to make the behavior configurable
>> with default the old behavior.
>>
>> Comments?
>>
> Not clear for me. Could you illustrate with an example ? thanks

Not really tested, but you might get the idea:

http://people.apache.org/~rjung/patches/jmeter-user_classpath-load_jars.patch

The added code is similar to the handling of jars in the method
addJarsInPath() called from findClassesThatExtend() of class ClassFinder.

Example is a jmeter extension (here a java sampler) that has lots of
dependencies. All of those (about 100) jars would need to be added to
user.classpath.

If we agree to include all jars located in some path component of
user.classpath automatically, then one could simply put the 100 jar
files in some directory, e.g. /my/sample/dependencies, and set

user.classpath=/my/sample/dependencies

For search_paths this already works, but not for user.classpath.

Regards,

Rainer

Re: user.classpath, search_path and many jar files

[Rainer Jung]

On 11.08.2013 23:40, Rainer Jung wrote:
> On 11.08.2013 21:45, Philippe Mouawad wrote:
>> On Fri, Aug 9, 2013 at 9:45 PM, Rainer Jung  wrote:
>>
>>> I have a situation where the user.classpath contains many jar files
>>> (about 100). Listing all of the jar files is tedious, difficult to
>>> maintain and not in any place where one can configure user.classpath
>>> possible or easy because of line length restrictions.
>>>
>>> Looking at the code I saw that in some places jar files lying in
>>> directories configured for class search are automatically also searched,
>>> but sometimes not.
>>>
>>> There are three cases:
>>>
>>> - not auto-searching the jar files:
>>>
>>> o.a.jmeter.JMeter start() calls updateClassLoader() calls updatePath()
>>> for search_paths and user.classpath. updatePath() calls
>>> NewDriver.addPath() for each path contained in those settings. Finally
>>> NewDriver.addPath() adds them to the system property "java.class.path"
>>> without listing all jar files contained in directories.
>>>
>>> So the class loader itself does not know about such jar files.
>>>
>>> - auto-searching such jar files in ClassFinder.findClassesThatExtend()
>>> using search_paths for JMeter extension:
>>>
>>> In findClassesThatExtend() a call to addJarsInPath() will automatically
>>> add all jar files found in a configured directory.
>>>
>>> - auto-searching jar files in user.classpath for JUnit setup:
>>>
>>> In JUnitTestSamplerGui the user.classpath property is used to search for
>>> classes extending Test or TestCase but the search is based on
>>> ClassFinder, so will automatically search through jar files.
>>>
>>> I propose to also add the jar files in the first case, the updatePath
>>> setting up the class loader. I guess the only concern would be the speed
>>> of class loading? IMHO if there are only few such jar files, then there
>>> should be no problem and if there are many such jar files, then not
>>> needing to configure them all is really helpful. So the remaining case
>>> is if there are many jar files auto-detected which are not really
>>> needed. That means it might make sense to make the behavior configurable
>>> with default the old behavior.
>>>
>>> Comments?
>>>
>> Not clear for me. Could you illustrate with an example ? thanks
> 
> Not really tested, but you might get the idea:
> 
> http://people.apache.org/~rjung/patches/jmeter-user_classpath-load_jars.patch
> 
> The added code is similar to the handling of jars in the method
> addJarsInPath() called from findClassesThatExtend() of class ClassFinder.
> 
> Example is a jmeter extension (here a java sampler) that has lots of
> dependencies. All of those (about 100) jars would need to be added to
> user.classpath.
> 
> If we agree to include all jars located in some path component of
> user.classpath automatically, then one could simply put the 100 jar
> files in some directory, e.g. /my/sample/dependencies, and set
> 
> user.classpath=/my/sample/dependencies
> 
> For search_paths this already works, but not for user.classpath.

Sorry my patch was rubbish. There are two types of user.classpath. I
changed the impl for the user.classpath given in the properties file.
But the entries there are also added to the system classpath, so you
don't want your extension dependencies there.

The correct patch is here:

http://people.apache.org/~rjung/patches/jmeter-user_classpath-load_jars-v2.patch

It adds the jar search to addURL() (called by TestPlan) instead of
addPath() (called by the main JMeter class).

addURL() only adds items to the loader, addPath() also to the system
classpath.

In the meantime I tested the patch and it works correct for me.

Now there's another thing that would be nice: being able to use a jmeter
property in the user defined class path in TestPlan.

Unfortunately that property is used very early and the resolution of
properties returns with an "Not running version, return raw function
string" error from FunctionProperty.

Is there a way to force a property replacement? Or how can we support
using a property in the user defined class path inside a test plan.

The use case is somewhat clear: you want to be able to collect your
dependency jars in some directory. When you relocate the directory you
don't want to edit all our test plans referring that directory. Instead
use a property in the test plans and set it during jmeter startup to
point to your current jar file directory.

Any hints would be helpful.

What about the patch for automatic jar file exclusion? Any objections?
Should I file a bugzilla before committing (it seems we now do it for
nearly every change)?

Regards,

Rainer

Re: user.classpath, search_path and many jar files

[Rainer Jung]

On 12.08.2013 14:59, Philippe Mouawad wrote:
> Hello Rainer,
> So your patch only concerns Test Plan which do "Add directory or jar to
> classpath" ?
> 
> If so, some notes about patch:
> 
>- Shouldn't code be within try/catch ? as if a MalformedURLException is
>thrown  there are big chances that the rest won't work

The NewDriver methods addURL() and addPath() have existing inconsistent
behavior. addPath() can throw the exception, so any call should be
inside try/catch, addURL() already does the try/catch internally so will
not throw it.

> Regarding Bugzilla, I think it is better to open one for this enhancement.

Will do.

Any idea about the property replacement:

>> Now there's another thing that would be nice: being able to use a jmeter
>> property in the user defined class path in TestPlan.
>>
>> Unfortunately that property is used very early and the resolution of
>> properties returns with an "Not running version, return raw function
>> string" error from FunctionProperty.
>>
>> Is there a way to force a property replacement? Or how can we support
>> using a property in the user defined class path inside a test plan.
>>
>> The use case is somewhat clear: you want to be able to collect your
>> dependency jars in some directory. When you relocate the directory you
>> don't want to edit all our test plans referring that directory. Instead
>> use a property in the test plans and set it during jmeter startup to
>> point to your current jar file directory.
>>
>> Any hints would be helpful.

Regards,

Rainer

Re: Rename "HTTP Proxy Server" ?

[Rainer Jung]

On 12.09.2013 20:38, sebb wrote:
> Would everyone be happy with the following?
> 
> HTTP(S) Test Script Recorder

OK

> On 11 September 2013 12:58, Philippe Mouawad  
> wrote:
>> Hello,
>> Web seems ambiguous to me
>>
>> For example, websocket is/will be web but Proxy cannot record it.
>> How about:
>> HTTP(S) Scenario Recorder or HTTP(S) Test Script Recorder.
>>
>>
>> Regards
>> Philippe
>>
>>
>>
>> On Wed, Sep 11, 2013 at 11:58 AM, Milamber  wrote:
>>
>>>
>>> Le 11/09/2013 10:42, sebb a ecrit :
>>>
>>>  On 11 September 2013 09:28, Milamber  wrote:

> I've prefer keep the word "proxy" in the name.
>
 That's the part I really want to get rid of, because of the potential
 confusion with the other proxy settings.

>>> Ok.
>>> (The word "proxy" means in my mind: "you must configure your browser to
>>> use this (JMeter) proxy to record your script".)
>>>
>>>
>>>
>>>
  "Test" is an ambiguous word, means in my mind "test" (like beta-test).
> Word
> like "script" seems better.
>
 Well, we use Test already quite a lot, as in Test Element / Test Script.

 Since JMeter is all about testing, I think using Test is OK.

  - HTTP(S) Proxy Recorder
> - HTTP(S) Proxy Test Recorder
> - Web Proxy Recorder
> - Web Proxy for Test Recorder
> - Web Proxy for Script Recorder
> - Web Proxy Script Recorder
>
>
> Web Proxy Recorder is my favorite.
>
>  How about

 Web Test Script Recorder

>>>
>>> +1 to this.
>>>
>>>
>>>
>>>  or
 Test Script Recorder - HTTP(S)
 or
 HTTP(S) Test Script Recorder

  Le 11/09/2013 09:00, Philippe Mouawad a ecrit :
>
>  HTTP(S) Test Recorder would be a good name I think.
>> But if we do the change we absolutely need to keep all references to
>> JMeter
>> Proxy Server as it is referenced on many links and documentations.
>>
>> Did you have some time to think about summariser enabling ?
>>
>> Great changes you made sebb !
>>
>> Thanks
>>
>> On Tuesday, September 10, 2013, sebb wrote:
>>
>>  The HTTP Proxy Server test element is used to record browser sessions
>>> as test plans.
>>>
>>> The name does not describe its function (it describes the
>>> implementation).
>>> Having Proxy in the name means it's more easily confused with the
>>> proxy settings that may be needed to run tests.
>>>
>>> I wonder if it would be a good idea to rename the test element to
>>> something like
>>>
>>> HTTP(S) Test Recorder
>>> or
>>> Test Recorder - HTTP(S)
>>> or
>>> Test Recorder - HTTP/HTTPS
>>>
>>> I did consider "Test Recorder" on its own, but that might be taken to
>>> imply that it can record other test types (e.g. JDBC), which it cannot
>>> at present. Even if we did implement JDBC recording, it would likely
>>> need a different GUI as the options would be completely different, so
>>> I think the name needs to include HTTP(S).
>>>
>>> I think the rename will only affect the component reference docs - and
>>> we can add an anchor for the old name.
>>>
>>> Thoughts?
>>> Would it help to rename the element?
>>>
>>> If there is agreement, I'd like to do this before the next release.
>>> There are other major changes to the recorder which also need
>>> documenting.
>>>
>>>
>>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.

Re: [VOTE] Release JMeter 2.10 RC2

[Rainer Jung]

On 17.10.2013 16:40, Milamber wrote:

> All feedback (and votes!) welcome.
> 
> [XX] +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)

+1 (binding), thanks for RM!

Details:

- MD5 OK
- signatures OK
- key in KEYS file

- gz and zip for src and bin consistent, except
  directory licenses/bin is only part of svn and the
  gz and zip bin distributions, but not part of
  the src distribution. So a bin distribution regenerated
  from the src distribution does not contain the files.
  Not a show-stopper IMHO.

- builds fine

- build result looks consistent with distribution, except for
  - timestamps in generated javadoc (expected)
  - binary jar files (expected)

- no Javadoc warnings

- ran the tests (but only with java.awt.headless)

- I have not checked the staging repository.

Build and tests were done using Java 1.6.0_45, OS was Solaris 10 Sparc.

Regards,

Rainer

Re: Twitter links

[Rainer Jung]

On 28.10.2013 12:40, sebb wrote:
> On 28 October 2013 08:46, Milamber  wrote:
>>
>> The last?:
>> https://people.apache.org/~milamber/wwwjmeter10/
>>
>> It's a 'mix' between 8 and 9. The ASF and JMeter logos have more space, and
>> JMeter logo is on the left even if the screen width changes.
> 
> That's better, but I still think the JMeter logo should be near the
> middle of the screen.
> 
> Anyone else got opinions on this?

For me having it left from the middle is OK, because the page doesn't
have a strong center symmetry. The menu on the left and the left
alignment of the second column together with many short lines in the
second column put the JMeter logo as it is now somehow close to the
gravitational center of the page. OK for me, but the bike shed could
also get some other color ;)

Thanks for the improvements!

Rainer

Re: Twitter links

[Rainer Jung]

On 28.10.2013 19:32, Milamber wrote:
> 
> Summary:
> Milamber : 10 or 8
> Philippe : 8
> Sebb : 9
> Rainer : 9 ?

Sory, I meant +1 to 10. My preferences are 10, then 8, then 9 based on
the latest URLs. I can live with all of them.

Regards,

Rainer

Re: [VOTE] Release JMeter 2.11 RC2

[Rainer Jung]

On 31.12.2013 19:09, Milamber wrote:
> Hello,
> 
> The 'second' release candidate for JMeter 2.11 (r1554548) has been
> prepared, and your votes are solicited.
> Note: RC1 has been aborted during release creation process.
> 
...
> 
> All feedback (and votes!) welcome.
> 
> [XX] +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.
> 
> 
> 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!
> 
> *--> AND Happy New Year ! <--*

The same to you!

+1 (binding), thanks for RM.

Details:

- MD5 OK
- signatures OK
- key in KEYS file

- gz and zip for src and bin consistent

- builds fine

- build result looks consistent with distribution, except for
  - timestamps in generated javadoc (expected)
  - some whitespace in javadoc (expected)
  - binary jar files (expected)

- no Javadoc warnings

- ran the tests (but only with java.awt.headless)

- I have not checked the staging repository.

Build and tests were done using Java 1.6.0_45, OS was Solaris 10 Sparc.

Regards,

Rainer

Re: Special Vote (2.10) : publish mongodb jar on Maven Central for JMeter 2.10

[Rainer Jung]

On 12.01.2014 10:12, Milamber wrote:
> Hello,
> 
> This a special vote for republish all the JMeter 2.10 jars on Maven
> central, including the missing mongodb jar file.
> (see https://issues.apache.org/bugzilla/show_bug.cgi?id=55965 )
> 
> All jars come directly from the original release directory (I have been
> the release manager, and I don't removed the release directory on my
> machine).
> I've only modify the build.xml to add the mongodb jar on maven_upload
> task (perhaps I need to commit this changes on 2.10 branch?)
> 
> You can check the jars in staging directory on Nexus:
> 
> https://repository.apache.org/content/repositories/orgapachejmeter-1000/org/apache/jmeter/
> 
> 
> You can vote:
> 
> [XX] +1  I support this update
> [  ] +0  I am OK with this update
> [  ] -0   OK, but
> [  ] -1   I do not support this  update (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 (binding)

Compared with original repos:

- mongodb added
- index.html some formal changes, probably due to a nexus change
- maven-metadata.xml changed  field
- maven-metadata.xml.md5 and maven-metadata.xml.sha1 changed accordingly

Thanks and regards,

Rainer

Re: Special Vote (2.11) : publish mongodb jar on Maven Central for JMeter 2.11

[Rainer Jung]

On 12.01.2014 10:27, Milamber wrote:
> Hello,
> 
> This a special vote for republish all the JMeter 2.11 jars on Maven
> central, including the missing mongodb jar file.
> (see https://issues.apache.org/bugzilla/show_bug.cgi?id=55965 )
> 
> All jars come directly from the original release directory (I have been
> the release manager, and I don't removed the release directory on my
> machine).
> I've only modify the build.xml to add the mongodb jar on maven_upload
> task (perhaps I need to commit this changes on 2.11 branch?)
> 
> You can check the jars in staging directory on Nexus:
> 
> https://repository.apache.org/content/repositories/orgapachejmeter-1001/org/apache/jmeter/
> 
> 
> You can vote:
> 
> [XX] +1  I support this update
> [  ] +0  I am OK with this update
> [  ] -0   OK, but
> [  ] -1   I do not support this  update (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 (binding)

Compared with original repos (same types of changes as for 2.10):

- mongodb added
- index.html some formal changes, probably due to a nexus change
- maven-metadata.xml changed  field
- maven-metadata.xml.md5 and maven-metadata.xml.sha1 changed accordingly

Thanks and regards,

Rainer

Re: Testing JMeter against JDK 8 EA builds

[Rainer Jung]

On 26.01.2014 11:43, Milamber wrote:
> Hello,
> 
> I've downloaded the Java 8 early access build for Linux 64bits.
> 
> I've made some simple tests with JMeter (2.12-SNAPSHOT) and try to build
> JMeter with Java 8.
> 
> I've found these issues:
> 
> On JMeter startup, we have these warnings:
> 
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=64m;
> support was removed in 8.0
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
> MaxPermSize=128m; support was removed in 8.0
> 
> Meaning that Java 8 don't offer to define the permanent memory size?

Yes, Java 8 integrated perm into heap and native memory (Metaspace).
There's no separate perm gen any more.

See e.g.

http://openjdk.java.net/jeps/122

http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-September/006679.html

http://java.dzone.com/articles/java-8-permgen-metaspace

No comments from me about the build errors. You didn't keep the OP on
CC, I don't know whether he is subscribed here and follows the list.

Regards,

Rainer

Re: JMeter Plugins and TestElement

[Rainer Jung]

On 19.02.2014 21:20, Philippe Mouawad wrote:
> Hello,
> http://jmeter.apache.org/extending/jmeter_tutorial.pdf
> 
> Regards
> 
> 
> On Wed, Feb 19, 2014 at 8:49 PM, Michael Lück wrote:
> 
>> Thanks Philippe,
>>
>> that's good to hear.
>>
>> could you point me to some resource where i can find more about the plugin
>> mechanism?

and also
http://jmeter.apache.org/usermanual/get-started.html#classpath

and in

http://jmeter.apache.org/usermanual/get-started.html#configuring_jmeter

look for user.classpath, search_paths and plugin_dependency_paths.

Note that their precise meaning was enhanced in 2.10, so if you are
using an older version you would need to look into the accompanying docs.

A remark about "plugin_dependency_paths": it can be used for dependency
libs needed by the plugins. If you would add them to lib/ext and there
were many of them, it would slow down startup a lot because the jars are
scanned for plugin classes.

Regards,

Rainer

Re: svn commit: r1572319 - in /jmeter/trunk: bin/jmeter.properties src/protocol/http/org/apache/jmeter/protocol/http/control/CacheManager.java xdocs/changes.xml

[Rainer Jung]

On 26.02.2014 23:47, s...@apache.org wrote:
> Author: sebb
> Date: Wed Feb 26 22:47:42 2014
> New Revision: 1572319
> 
> URL: http://svn.apache.org/r1572319
> Log:
> HTTP Cache Manager should not cache PUT/POST etc.
> Bugzilla Id: 56162
> 
> Modified:
> jmeter/trunk/bin/jmeter.properties
> 
> jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/control/CacheManager.java
> jmeter/trunk/xdocs/changes.xml
> 
> Modified: jmeter/trunk/bin/jmeter.properties
> URL: 
> http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.properties?rev=1572319&r1=1572318&r2=1572319&view=diff
> ==
> --- jmeter/trunk/bin/jmeter.properties (original)
> +++ jmeter/trunk/bin/jmeter.properties Wed Feb 26 22:47:42 2014
> @@ -386,6 +386,14 @@ log_level.jorphan=INFO
>  #httpclient3.retrycount=0
>  
>  #---
> +# HTTP Cache Manager configuration
> +#---
> +#
> +# Space or comma separated list of methods that can be cached
> +cacheable_methods=GET
> +# N.B. This property is currently a temporary solution for Bug 56162

Is HEAD in this context handled like GET, or should we also add it to
the default?

Regards,

Rainer

Re: [ANNOUNCE] Felix Schumacher as new commiter on JMeter

[Rainer Jung]

Am 02.10.2014 um 07:17 schrieb Milamber:


Congratulations Felix!


+1

Nice to have you here.

Rainer


On 01/10/2014 23:43, Philippe Mouawad wrote:

The Project Management Committee (PMC) for Apache JMeter has asked Felix
Schumacher to become a committer and we are pleased to announce that
he has
accepted.

Being a committer allows many contributors to contribute more
autonomously.
For developers, it makes it easier to submit changes and eliminates the
need to have contributions reviewed via the patch submission process.
Whether contributions are development-related or otherwise, it is a
recognition of a
contributor's participation in the project and commitment to the
project and
the Apache Way.

Please join me in congratulating Felix!

-Philippe M.
For the JMeter PMC.

Re: [ANNOUNCE] Andrey Pohilko as new commiter on JMeter

[Rainer Jung]

Am 13.10.2014 um 21:16 schrieb Philippe Mouawad:

The Project Management Committee (PMC) for Apache JMeter has asked Andrey
Pohilko to become a committer and we are pleased to announce that he has
accepted.

Andrey Pohilko is founder of http://jmeter-plugins.org and among other
things a well-known performance expert.

Being a committer allows many contributors to contribute more autonomously.
For developers, it makes it easier to submit changes and eliminates the
need to have contributions reviewed via the patch submission process.
Whether contributions are development-related or otherwise, it is a
recognition of a
contributor's participation in the project and commitment to the project and
the Apache Way.

Please join me in congratulating Andrey !


Congrats and welcome!

Rainer

Re: [ANNOUNCE] Mikhail Epikhin as new commiter on JMeter

[Rainer Jung]

Am 15.10.2014 um 06:37 schrieb Milamber:


Welcome and congrats Mikhail!


+1 !

Rainer


On 14/10/2014 21:19, Philippe Mouawad wrote:

The Project Management Committee (PMC) for Apache JMeter has asked
Mikhail
Epikhin to become a committer and we are pleased to announce that he has
accepted.

Being a committer allows many contributors to contribute more
autonomously.
For developers, it makes it easier to submit changes and eliminates the
need to have contributions reviewed via the patch submission process.
Whether contributions are development-related or otherwise, it is a
recognition of a
contributor's participation in the project and commitment to the
project and
the Apache Way.

Please join me in congratulating Mikhail !

-Philippe M.
For the JMeter PMC.

Re: [VOTE] Release JMeter 2.12 RC2

[Rainer Jung]

Am 05.11.2014 um 23:17 schrieb Milamber:

Hello,

The second release candidate for JMeter 2.12 (r1636949) has been
prepared, and your votes are solicited.

...


All feedback and vote are welcome.

[XX] +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)


+1 (binding), thanks for RM.

Details:

- MD5 OK
- signatures OK
- key in KEYS file
- gz and zip for src and bin consistent
- svn and gz/zip mostly consistent
  - "bin/mirror-server" missing from dist,
not a showstopper, since mirror-server.sh
is included and mirror-server is only a trivial wrapper
Fixed in svn by r1637321.
  - Revision number in line

(expected)
- builds fine
- build result looks consistent with distribution, except for
  - timestamps in generated javadoc (expected)
- should we exclude those? Javadoc has a flag to
  not generate the timestamps.
  - some whitespace in javadoc (expected)
  - binary jar files (expected)
- no Javadoc warnings when building with Java 6 or 7
- some Javadoc warnings when building with Java 8
  - Details see below
- ran the tests (but only with java.awt.headless)
- I have not checked the staging repository.
- I have not checked tha rat report

Build and tests were done using Java 1.6.0_45, 1.7.0_51 and 1.8.0, OS 
was Solaris 10 Sparc.


Javadoc Warnings under Java 8:

/src/core/org/apache/jmeter/JMeter.java:274: warning: no @param for args
/src/core/org/apache/jmeter/JMeter.java:847: warning: no description for 
@param
/src/reports/org/apache/jmeter/JMeterReport.java:299: warning: no 
description for @param
/src/core/org/apache/jmeter/NewDriver.java:190: warning: no description 
for @param
/src/core/org/apache/jmeter/NewDriver.java:200: warning: no description 
for @throws
/src/core/org/apache/jmeter/util/BeanShellTestElement.java:137: warning: 
no description for @throws
/src/core/org/apache/jmeter/testelement/TestElement.java:79: warning: no 
@return
/src/core/org/apache/jmeter/testelement/TestElement.java:85: warning: no 
description for @param
/src/core/org/apache/jmeter/testelement/TestElement.java:102: warning: 
no @param for key
/src/core/org/apache/jmeter/testelement/TestElement.java:102: warning: 
no @return
/src/core/org/apache/jmeter/testelement/TestElement.java:126: warning: 
no @param for run
/src/core/org/apache/jmeter/testelement/TestElement.java:149: warning: 
no @param for property
/src/core/org/apache/jmeter/testelement/TestElement.java:155: warning: 
no @param for propName
/src/core/org/apache/jmeter/testelement/TestElement.java:155: warning: 
no @return
/src/core/org/apache/jmeter/testelement/TestElement.java:173: warning: 
no @param for traverser
/src/core/org/apache/jmeter/gui/Searchable.java:29: warning: no 
description for @throws
/src/core/org/apache/jmeter/testelement/AbstractScopedTestElement.java:71: 
warning: no description for @param
/src/core/org/apache/jmeter/testelement/AbstractScopedTestElement.java:81: 
warning: no description for @param
/src/core/org/apache/jmeter/testelement/AbstractScopedTestElement.java:91: 
warning: no description for @param
/src/core/org/apache/jmeter/testelement/AbstractScopedTestElement.java:101: 
warning: no description for @param
/src/components/org/apache/jmeter/assertions/HTMLAssertion.java:260: 
warning: no description for @param
/src/components/org/apache/jmeter/assertions/HTMLAssertion.java:273: 
warning: no description for @param
/src/components/org/apache/jmeter/assertions/HTMLAssertion.java:282: 
warning: no description for @param
/src/components/org/apache/jmeter/assertions/HTMLAssertion.java:298: 
warning: no description for @param
/src/components/org/apache/jmeter/assertions/HTMLAssertion.java:371: 
warning: no description for @param
/src/core/org/apache/jmeter/util/JSR223TestElement.java:135: warning: no 
description for @throws
/src/core/org/apache/jmeter/util/JSR223TestElement.java:136: warning: no 
description for @throws
/src/components/org/apache/jmeter/assertions/SizeAssertion.java:113: 
warning: no @return
/src/components/org/apache/jmeter/assertions/SizeAssertion.java:120: 
warning: no @param for operator
/src/components/org/apache/jmeter/assertions/SizeAssertion.java:130: 
warning: no @return
/src/components/org/apache/jmeter/assertions/XPathAssertion.java:159: 
warning: no description for @param
/src/components/org/apache/jmeter/assertions/XPathAssertion.java:168: 
warning: no description for @param
/src/components/org/apache/jmeter/assertions/XPathAssertion.java:177: 
warning: no description for @param
/src/core/org/apache/jmeter/gui/AbstractScopedJMeterGuiComponent.java:91: warning: 
no description for @param
/src/core/org/apache/jmeter/gui/AbstractScopedJMeterGuiComponent.java:110: 
warning: no description for @param
/src/core/org/apache/jmeter/gui/AbstractScopedJMeterGuiComponent.java:119: 
warning: no description for @param
/src/core/org/apache/jmeter/gui/AbstractScopedJMeterGuiComponent.java:12

Re: [VOTE] Release JMeter 2.12 RC2

[Rainer Jung]

Hi Milamber,

Am 09.11.2014 um 11:40 schrieb Milamber:

Hello Rainer,

Thanks for your complete test and your little fixes.


NP, easy doing.


 - should we exclude those? Javadoc has a flag to
   not generate the timestamps.

Yes why not, what is the flag?


Added in r1637691.


I will open a bugzilla ticket to fix the javadoc (8) warning for the new
release.


ACK, thanks! It was the first time I actually have built JMeter using 
Java 8 and was surprised javadoc behavior changed.


Rainer

Re: Introduce connect times for SampleResult?

[Rainer Jung]

Am 03.12.2014 um 15:15 schrieb Andrey Pokhilko:

Happened to be not so much work:
https://github.com/apache/jmeter/pull/11/files

Please, review it and point me at any changes needed.


I didn't review the patch but I patched a 2.12 I'm currently using to 
probe a service and it seems to run well here.


Regards,

Rainer


On 11/29/2014 04:06 PM, sebb wrote:

On 29 November 2014 at 12:14, Andrey Pokhilko  wrote:

Hi,

Many times I see a sence to have connect times measured separately, in
addition to latency that we have in SampleResult. It is important when
measuring a time for SSL handshake and DNS resolving, when users want to
see it separate share in total Response Time.

Connect time is available as separate metric in Grinder and Yandex.Tank.
The latter has following details on response time pars: connect, send,
latency, receive. Sometimes some parts are zero, but at least there is a
technical possibility to see when it is non-zero. It should be noted
that full breakdown would be: dns, connect, send, latency, receive.

Send and receive times are not of great importance, IMO. And I would
cope with connect time including DNS resolve time. But having connect
time would add interesting aspect on results.

[I expect DNS resolve time might be very tricky to measure in Java]


For implementation it will require adding one more property with getters
and setters to SampleResult, modifying SampleSaveConfiguration and UI
settings to configure saving, using this new field in HTTP sampler, TCP
sampler, maybe there are other samplers that can respect this field.

The docs would need to be updated to state whether a sampler supports
the metric or not.


As separate question I would raise if latency should not include connect
time, for me it sounds logical, but changes existing behavior.

Connect time is currently included in both latency and elapsed.

The simplest would be to just add connect as a separate time, but not
subtract it from latency or elapsed.
This would allow further analysis without changing behaviour.
Maybe add an option to perform the subtraction.
I don't think we should change the default behaviour.


Any opinions?

I can see its use and am not against it, but it needs quite a lot of
work to implement fully.


--
Andrey Pokhilko

Re: Converter#getCalendar(Object, Calendar)

[Rainer Jung]

Hi Felix,

Am 31.12.2014 um 15:49 schrieb Felix Schumacher:

Am 28.12.2014 um 23:53 schrieb sebb:



-1

I don't think it's a good idea to tamper with this method.
There are no unit tests for it, and it is used for preparing the
TestBeans.

If any subtle changes are introduced it may prove very difficult to
debug.

Very well, the unit tests are there already :) But as you are against
it, I will not submit the changes. However if anyone likes to look at
them, I have attached them.


The attachment either got stripped or was missing.

Happy new year,

Rainer

Re: Java version check in jmeter script files - is it worth the maintenance effort?

[Rainer Jung]

Am 23.02.2015 um 19:36 schrieb sebb:

The Java version check in JMeter script files is somewhat fragile, and
has to be maintained.

Does it really provide enough benefit to keep it?


IMHO currently there's no real necessity to remove it, or did you find 
another problem with it? I suspect you ask, because there's always 
exotic systems and writing portable shell scripts is a hard task and one 
can't easily test them (because the platforms are not available).


Since our requirements are very relaxed (Java 6), there's no big use in 
the version check either. In most cases the condition will be fulfilled, 
so a clear documentation statement should suffice. I think currently the 
info is only on the download page and in the changelog. Maybe it could 
be added to the "a 100% pure Java application" sentence in the landing 
page and in the intro page of the users manual without bloating that 
pages to much.


So I'm fine with either keeping or removing the check, but I think we 
should place the requirement a little bit more prominent in the docs in 
any case.


Regards,

Rainer

Re: JMeter 2.12 Transitive Dependency Issues

[Rainer Jung]

Am 28.02.2015 um 16:08 schrieb Mark Collin:

Just a quick heads up about this bug

https://bz.apache.org/bugzilla/show_bug.cgi?id=57649


This should be a dublicate of BZ 57555 fixed in r1659390.


It would be good to have a test that checks to see if there are any transitive 
dependency issues in maven after the POMs are built.


True. Any implementation suggestion for that?

Regards,

Rainer

Re: [VOTE] Release JMeter 2.13 RC2

[Rainer Jung]

Am 08.03.2015 um 23:00 schrieb Milamber:

Hello,

The second release candidate for JMeter 2.13 (r1665067) has been
prepared, and your votes are solicited.

This release brings some new features and fixes some bugs.

On this occasion, we also refreshes the style of JMeter's website. You
can preview by visiting this URL:
http://people.apache.org/~milamber/jmeter-2.13RC2/docs/

If you can, some tests of this release candidate (load tests and/or
functional tests) with Java 6/7/8 on Linux/Windows/Mac OS on changes are
welcome.

You can read the New and Noteworthy section with some screenshots to
illustrate improvements and full list of changes at:
http://people.apache.org/~milamber/jmeter-2.13RC2/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 6+.

Archives/hashes/sigs:

https://dist.apache.org/repos/dist/dev/jmeter/v2.13_RC2/

RAT report:

http://people.apache.org/~milamber/jmeter-2.13RC2/dist/rat-report-jmeter-2.13RC2.txt

(please note: you need build the latest version of RAT: 0.12-SNAPSHOT to
generate the report. Reason unknown, but the version 0.11 don't work
(loop running indefinitely))

MD5 hashes of archives for this vote:

53dc44a6379b7b4a57976936f3a65e03 *apache-jmeter-2.13.tgz
3bf9df356588bb12062f9c082f326b9f *apache-jmeter-2.13.zip
d822e0e822ab03769e206f4fa1d6b0f5 *apache-jmeter-2.13_src.tgz
25900c01368fdcf7b69ffd27a4f155ad *apache-jmeter-2.13_src.zip

Site Docs are here:
http://people.apache.org/~milamber/jmeter-2.13RC2/docs/

Maven staging repo is accessible here:
https://repository.apache.org/content/repositories/orgapachejmeter-1005/org/apache/jmeter/

Tag:
http://svn.apache.org/repos/asf/jmeter/tags/v2_13_RC2/

Keys are here:
http://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 2.13 requires Java 6 or later to run.

Some known issues and incompatible changes are listed on changes page.
http://people.apache.org/~milamber/jmeter-2.13RC2/docs/changes.html


All feedback and vote are welcome.

[XX] +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.


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!


Sorry for being late.

+1 (binding), thanks for RM.

Details:

- MD5 OK
- signatures OK
- key in KEYS file
- gz and zip for src and bin consistent
- svn and gz/zip mostly consistent
  - Revision number in build.xml (expected):

- builds fine
- build result looks consistent with distribution, except for
  - some ordering in javadoc (expected)
  - binary jar files (expected)
- no Javadoc warnings when building with Java 6
- some Javadoc warnings when build with Java 7:

.../src/components/org/apache/jmeter/visualizers/RenderAsXPath.java:LINE: warning 
- @return tag has no arguments.
.../src/protocol/http/org/apache/jmeter/protocol/http/proxy/ProxyControl.java:LINE: 
warning - @return tag has no arguments.
.../src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java:LINE: 
warning - @return tag has no arguments.


- some Javadoc warnings when building with Java 8

.../src/core/org/apache/jmeter/engine/DistributedRunner.java:LINE: 
warning: no description for @throws

 * @throws RemoteException
   ^
.../src/core/org/apache/jmeter/engine/DistributedRunner.java:LINE: 
warning: no description for @throws

 * @throws NotBoundException
   ^
.../src/core/org/apache/jmeter/engine/DistributedRunner.java:LINE: 
warning: no description for @throws

 * @throws MalformedURLException
   ^

- new dependencies (expected)
  - Introduced for new Async BackendListener
- commons-math3-3.4.1.jar
- commons-pool2-2.3.jar
- "reports" package dropped (expected)
- ant target "compile-rmi" removed (expected)
- ran the tests (but only with java.awt.headless)
- I have not checked the staging repository.
- I have not checked the rat report

Build and tests were done using Java 1.6.0_45, 1.7.0_76 and 1.8.0_31, OS 
was Solaris 10 Sparc.


Regards,

Rainer

VSL files and new-style.css

[Rainer Jung]

Hi,

in the two files xdocs/stylesheets/site.vsl and 
xdocs/stylesheets/site_printable.vsl there is still a reference to the 
previous style.css:




Should this be changed to new-style.css? I'm not really sure about when 
the vsl files are used and when the xsl files, but it seems for the sake 
of consistency the file name should be adjusted in the vsl files.


Regards,

Rainer

Re: VSL files and new-style.css

[Rainer Jung]

Am 16.03.2015 um 01:50 schrieb sebb:

On 15 March 2015 at 15:20, Rainer Jung  wrote:

Hi,

in the two files xdocs/stylesheets/site.vsl and
xdocs/stylesheets/site_printable.vsl there is still a reference to the
previous style.css:



Should this be changed to new-style.css? I'm not really sure about when the
vsl files are used and when the xsl files, but it seems for the sake of
consistency the file name should be adjusted in the vsl files.


Originally there were both XSL and VSL files for both site docs and
printable docs (as used by JMeter itself).
The XSL stylesheets were gradually phased out for both, as it was
easier to maintain the VSL files.

The site refresh now uses XSL again.
However the printable docs still use VSL as  far as I am aware, and
the new style sheet is *not* applicable.


OK, so I understand that adjusting the vsl to use the new style sheet 
would not be the right thing to do.


Rainer

Re: Component adding hotkeys

[Rainer Jung]

Am 30.04.2015 um 14:49 schrieb Philippe Mouawad:

Hi,
I think it's a nice idea, we have same the same feedback.

For me it should be in core once linux issue is fixed, what about tested
platforms:
- Windows 8? 7 ?
- Linux
- Mac OSX ? which os ?

Regarding other questions, answers inline.

Regards
On Monday, April 27, 2015, Andrey Pokhilko > wrote:


Hi,

I have colleagues that do heavy JMeter scripting and they come with idea
to speed-up the process: have hotkeys to add JMeter components to test
plan. Using a hotkey eliminates the need to walk through context menus.
As always, Pareto principle states that 80% of a time people use 20% of
components, so small set of hotkeys would cover most of situations.

I have implemented this feature as Ctrl+0 .. Ctrl+9 hotkey set, with
components configurable through properties. Components are added as a
child of current position, if possible, or a sibling at the nearest
possible scope. I provided my colleagues with patched JMeter and they
found the feature working smoothly.

Pull request for easy review is here:
https://github.com/apache/jmeter/pull/16 , I will create bugzilla for
this when needed.

As always I ask if other committers support adding this into main JMeter
codebase or not.

Some notes/questions from my side:

   * Where is appropriate place in the docs to document this feature?


Somewhere where Search Feature and templates are documented




   * Are defaults good? What are most used JMeter components?



I would remove or put them at end:
View Results Tree
User Defined Variables
Test Fragment

as although popular you rarely add more than 2 or 3.

I would add :
- Css/JQuery extractor
- Jsr223 Post processor
- Test Action for the timer discussion we had
- JSR223 Pre processir
-Debug Sampler


Often the interesting shortcuts depend on the type of test your are 
preparing. So I wonder if there could be a new hotkey config element one 
could include in a test plan, that - if found - would override the 
configured JMeter hotkeys with the ones defined in this element. With 
that you would carry your hotkeys with your test plan (and hopefully 
templates).


Now that maybe would open a can of worms, because the same idea could be 
useful for other settings as well and user could start to demand more 
and more GUI for JMeter user properties setting. So maybe another idea 
could be a startup config element in a plan that would contain a list 
(key, value) of additional user properties that would be merged after 
loading the test plan. It probably wouldn't work cleanly for all 
properties because it comes too late for some, but for many it could 
work and be helpful.


Probably all too complex but wanted to throw the idea up in the air.

Regards,

Rainer

Re: Create Macro Feature was Post-Sampler Timers

[Rainer Jung]

Am 09.05.2015 um 11:56 schrieb Vladimir Sitnikov:

Add "remember position" value to 'Start from line' property, so when
used it would store the position in some side file (that is tricky in
terms of picking the proper storage folder for it and avoiding write
on each line fetch).


I'd suggest use the same folder and file name as for the CSV file, but 
add a fixed suffix, e.g. ".state" or ".last" to the end of the file name.


When to save? IMHO once at end of test run. Saving after each iteration 
is too much.


We would need to document the mechanism, so people would know how to 
reset (remove the file) and that the "Start form line" property is no 
longer effective once you have successfully used "remember position".


Regards,

Rainer

Re: Update to minimum Java 7

[Rainer Jung]

Am 01.06.2015 um 15:39 schrieb Philippe Mouawad:

As per dev mailing list thread which could have been reused for this:
-
http://mail-archives.apache.org/mod_mbox/jmeter-dev/201411.mbox/%3ccaogo0vb1ffpuipcc0flqhfn2oyhvtss2r90ntgm7gqsh2m_...@mail.gmail.com%3E

+1 for me.
Among additional reasons to what has been exposed:

1/ There is a new method in Java 7 that is interesting for performances (
http://download.java.net/jdk7/archive/b123/docs/api/java/net/InetSocketAddress.html#getHostString%28%29)
instead of getHostName() which makes a reverse lookup, see
http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201302.mbox/%3C1360057832.23610.6.camel@ubuntu%3E.
See:
https://issues.apache.org/bugzilla/show_bug.cgi?id=54449
And I noticed sometimes this method could slowdown JMeter startup in
certain network conditions, until the reverse lookup timeouts
2/ Better String implementation (We need to take care) =>
http://java-performance.info/changes-to-string-java-1-7-0_06/
3/ We have a copy of Doug Lea's class for Random that is in JDK7
4/ We can expect our dependencies to drop JDK6 support in near future
5/ Better NIO support in recent JDK versions which we could use in some
features discussed in RoadMap thread

Regards
@philmdot


On Mon, Jun 1, 2015 at 3:17 PM, Andrey Pokhilko  wrote:


+100500

Andrey Pokhilko

On 06/01/2015 04:14 PM, sebb wrote:

I think we should require a minimum of Java 7 for the next JMeter

release.

(It currently requires 1.6)

This is because:
- Java 7 supports proper certificate generation for the HTTP recorder.
It will probably allow some code simplification.
- the Javadoc vulnerability CVE-2013-1571 has been fixed since Java 7
update 25 (June 2013). We could drop the patch.
- any others?

Of course Java 7 is just about EOL, but I've not yet seen any
compelling reasons to require a minimum of Java 8. If there are such
reasons (other than Java 7 is EOL) please raise them here.

A very minor consideration is that Javadoc 7 seems to have been fixed
to generate lower-case HTML tags - e.g.  rather than . I
assume that will remain the case. So there will be a once-off SVN
difference when older API docs are replaced with new ones.


+1: lots of good reasons listed. Only very few users should have 
problems to get Java 7 to their test environments. Mostly some not-well 
maintained enterprise desktops. And I also think for Java 8 it is a bit 
to early (despite Java 7 being EOL quite a few users might have a 
problem getting Java 8 into their environment if it is centrally but not 
well managed).


Regards,

Rainer

Re: SMTP Sampler and TLSv1.2/CipherSuites

[Rainer Jung]

Am 06.06.2015 um 17:59 schrieb Felix Schumacher:

Hi all,

to enable the SMPT Sampler to use a higher TLS version than TLSv1 it
seems to be necessary to change the SSLContext.getInstance call in
TrustAllSSLSocketFactory from "TLS" to "TLSv1.2".


Any idea why? When I test java HTTP connectivity, then "TLS" is able to 
connect TLSv1.2 if the JVM is new enough end the server supports it. 
"TLS" in getInstance() is not very wel documented, but in general seems 
to support al TLS versions trying to use the newest one supported by 
both sides.


There's also the possibility to set enabledProtocols() which does not 
support the string "TLS", but only the explicit protocol versions. But 
even without setting enabled protocols and just sticking to defaults,I 
can get a TLSv1.2 (HTTP) connection with Java 8 and e.g. a TLSv1 
connection with Java 6, both creating the SSLContext via getInstance("TLS").


Is there a public SMTP server which can be used to observe the problem 
you see?


Regards,

Rainer

Re: SMTP Sampler and TLSv1.2/CipherSuites

[Rainer Jung]

Am 07.06.2015 um 15:16 schrieb sebb:

On 7 June 2015 at 13:10, Felix Schumacher
 wrote:

Am 07.06.2015 um 11:12 schrieb Rainer Jung:


Am 06.06.2015 um 17:59 schrieb Felix Schumacher:


Hi all,

to enable the SMPT Sampler to use a higher TLS version than TLSv1 it
seems to be necessary to change the SSLContext.getInstance call in
TrustAllSSLSocketFactory from "TLS" to "TLSv1.2".



Any idea why? When I test java HTTP connectivity, then "TLS" is able to
connect TLSv1.2 if the JVM is new enough end the server supports it. "TLS"
in getInstance() is not very wel documented, but in general seems to support
al TLS versions trying to use the newest one supported by both sides.

There's also the possibility to set enabledProtocols() which does not
support the string "TLS", but only the explicit protocol versions. But even
without setting enabled protocols and just sticking to defaults,I can get a
TLSv1.2 (HTTP) connection with Java 8 and e.g. a TLSv1 connection with Java
6, both creating the SSLContext via getInstance("TLS").


I have done my tests using java 7. When I repeated them with java 8 (after I
wrote the text below), I got the same results, as you reported. So it seems
to be a problem with java 7 only.



Is there a public SMTP server which can be used to observe the problem you
see?


I have used a docker image (catatnight/postfix) with self signed certs.
Instead of running it directly, I started a shell with it:

$ docker run -ti -p 587:587  -e maildomain=whatever.local -e
smtp_user=user:pwd -v "${PATH_TO_CERTS}":/etc/postfix/certs
catatnight/postfix /bin/bash

Inside the new prompt I used the install.sh script from the docker image, so
that my keys get used and disabled every protocol except TLSv1.2:

root@abc...:/# /opt/install.sh
# Some message about missing dkim keys (can be ignored)
root@abc...:/# postconf -e 'smtpd_tls_mandatory_protocols=TLSv1.2'
root@abc...:/# service postfix start
# Message that postfix started

In another terminal I used openssl to connect to the server with TLSv1.2
(success) and TLSv1.2 (no success) using:

$ openssl s_client -tls1_2 -starttls smtp -connect localhost:587
# ...
# ---
# 250 DSN
quit
$ openssl s_client -tls1_1 -starttls smtp -connect localhost:587
# ...
# ---
$

With this setup and the getInstance("TLS") I got no connection, while
getInstance("TLSv1.2") gave me a connection.

When I start the postfix server in its default configuration (every protocol
allowed except SSLv2), JMeter is able to make a connection, but will use
TLSv1 only.

This test was done on ubuntu 14.04 LTS with OpenJDK 1.7.0_79. And after I
wrote this text I repeated the tests with Oracles java versions 1.7.0_80,
1.8.0_45 and 1.9.0-ea-b66 where java 8 and 9 successfully created a
connection with getInstance("TLS") and java 7 did not.

So it seems to be a problem with java 7 and getInstance("TLS") only.

Should we still add a system property to influence the selection of the used
protocol?


It won't do any harm, and might help some users, so I suggest we add
the property.


Not that there's two knobs one can turn: the so called protocol used in 
getInstance() which can be a real protocol, but also the token "TLS", 
and the list or protocols passed to SSLSocket.enabledProtocols(). The 
interaction between the two is not well documented, but it might be 
better keeping protocol as TLS but explicitely enabling protocols via 
enabledProtocols. The supported protocols are available via 
getSupportedSSLParameters().getProtocols().


Regards,

Rainer

Re: Is the git repo still being synched?

[Rainer Jung]

Am 07.06.2015 um 15:35 schrieb Milamber:


ASF svn US service has been migrate to a new host last friday, perhaps
something are wrong with Github/new config.

@sebb, do you know the process to synchronize with github or we need to
open ticket on Infra?


Github seems to sync from the ASF git repos, and the ASF git repos for 
jmeter is also unchanged since Friday.


I will see if I can get a short comment from infra via chat whether it 
is a known problem or not.


Rainer


On 07/06/2015 14:11, Felix Schumacher wrote:

Am 07.06.2015 um 15:09 schrieb Milamber:



On 07/06/2015 13:54, Felix Schumacher wrote:

Hi all,

it seems, that the git repo is not being synched with svn anymore.
The newest change I can see is from last friday at 20:15.


Which git repo ? ASF or Github?

I looked at github.





Could it be related to the svn work?

Regards
 Felix

Re: Is the git repo still being synched?

[Rainer Jung]

Am 07.06.2015 um 15:38 schrieb Rainer Jung:

Am 07.06.2015 um 15:35 schrieb Milamber:


ASF svn US service has been migrate to a new host last friday, perhaps
something are wrong with Github/new config.

@sebb, do you know the process to synchronize with github or we need to
open ticket on Infra?


Github seems to sync from the ASF git repos, and the ASF git repos for
jmeter is also unchanged since Friday.

I will see if I can get a short comment from infra via chat whether it
is a known problem or not.


It seems currently noone can answer via chat (Sunday). It is known 
though that the server migration on Friday didn't go well. I'll keep an 
eye on who is hanging around and ask again later today, opening an issue 
if it seems appropriate.


Regards,

Rainer

Re: SMTP Sampler and TLSv1.2/CipherSuites

[Rainer Jung]

Am 07.06.2015 um 17:32 schrieb Felix Schumacher:

Am 07.06.2015 um 15:24 schrieb Rainer Jung:

Am 07.06.2015 um 15:16 schrieb sebb:

On 7 June 2015 at 13:10, Felix Schumacher
 wrote:

Am 07.06.2015 um 11:12 schrieb Rainer Jung:


Am 06.06.2015 um 17:59 schrieb Felix Schumacher:


Hi all,

to enable the SMPT Sampler to use a higher TLS version than TLSv1 it
seems to be necessary to change the SSLContext.getInstance call in
TrustAllSSLSocketFactory from "TLS" to "TLSv1.2".



Any idea why? When I test java HTTP connectivity, then "TLS" is
able to
connect TLSv1.2 if the JVM is new enough end the server supports
it. "TLS"
in getInstance() is not very wel documented, but in general seems
to support
al TLS versions trying to use the newest one supported by both sides.

There's also the possibility to set enabledProtocols() which does not
support the string "TLS", but only the explicit protocol versions.
But even
without setting enabled protocols and just sticking to defaults,I
can get a
TLSv1.2 (HTTP) connection with Java 8 and e.g. a TLSv1 connection
with Java
6, both creating the SSLContext via getInstance("TLS").


I have done my tests using java 7. When I repeated them with java 8
(after I
wrote the text below), I got the same results, as you reported. So
it seems
to be a problem with java 7 only.



Is there a public SMTP server which can be used to observe the
problem you
see?


I have used a docker image (catatnight/postfix) with self signed certs.
Instead of running it directly, I started a shell with it:

$ docker run -ti -p 587:587  -e maildomain=whatever.local -e
smtp_user=user:pwd -v "${PATH_TO_CERTS}":/etc/postfix/certs
catatnight/postfix /bin/bash

Inside the new prompt I used the install.sh script from the docker
image, so
that my keys get used and disabled every protocol except TLSv1.2:

root@abc...:/# /opt/install.sh
# Some message about missing dkim keys (can be ignored)
root@abc...:/# postconf -e 'smtpd_tls_mandatory_protocols=TLSv1.2'
root@abc...:/# service postfix start
# Message that postfix started

In another terminal I used openssl to connect to the server with
TLSv1.2
(success) and TLSv1.2 (no success) using:

$ openssl s_client -tls1_2 -starttls smtp -connect localhost:587
# ...
# ---
# 250 DSN
quit
$ openssl s_client -tls1_1 -starttls smtp -connect localhost:587
# ...
# ---
$

With this setup and the getInstance("TLS") I got no connection, while
getInstance("TLSv1.2") gave me a connection.

When I start the postfix server in its default configuration (every
protocol
allowed except SSLv2), JMeter is able to make a connection, but will
use
TLSv1 only.

This test was done on ubuntu 14.04 LTS with OpenJDK 1.7.0_79. And
after I
wrote this text I repeated the tests with Oracles java versions
1.7.0_80,
1.8.0_45 and 1.9.0-ea-b66 where java 8 and 9 successfully created a
connection with getInstance("TLS") and java 7 did not.

So it seems to be a problem with java 7 and getInstance("TLS") only.

Should we still add a system property to influence the selection of
the used
protocol?


It won't do any harm, and might help some users, so I suggest we add
the property.


Not that there's two knobs one can turn: the so called protocol used
in getInstance() which can be a real protocol, but also the token
"TLS", and the list or protocols passed to
SSLSocket.enabledProtocols(). The interaction between the two is not
well documented, but it might be better keeping protocol as TLS but
explicitely enabling protocols via enabledProtocols. The supported
protocols are available via getSupportedSSLParameters().getProtocols().


After reading a bit more and doing some testing I think I have found an
easier solution, which is probably the correct way to do it.

javamail has a property "mail.smtp.ssl.protocols" which takes a space
separated list of protocols, that can be used for a new connection. If I
set it to "SSLv3 TLSv1 TLSv1.1 TLSv1.2" then even my java 7 installation
will connect to a server that only supports TLSv1.2.

I don't have to change getInstance("TLS").


That makes sense to me. The Javadoc for that property says that the 
values will be used in the call SSLSocket.setEnabledProtocols().


The only problem is if we use a protocol name in the list which is 
actually not supported by the JVM version. That would result likely in a 
java.lang.IllegalArgumentException: TLSv1.1.


Currently, since we want to demand Java 7, there's no difference between 
the list for Java 7 and 8. The problem will show up sometime in the 
future when TLS 1.3 becomes available. Maybe not important enough for 
now. If you like you could instead use the list available via 
SSLContext.getSupportedSSLParameters().getProtocols().


Regards,

Rainer

Re: SMTP Sampler and TLSv1.2/CipherSuites

[Rainer Jung]

Looks good to me!

Am 07.06.2015 um 19:56 schrieb Felix Schumacher:

Am 07.06.2015 um 18:59 schrieb Rainer Jung:

Am 07.06.2015 um 17:32 schrieb Felix Schumacher:

Am 07.06.2015 um 15:24 schrieb Rainer Jung:

Am 07.06.2015 um 15:16 schrieb sebb:

On 7 June 2015 at 13:10, Felix Schumacher
 wrote:

Am 07.06.2015 um 11:12 schrieb Rainer Jung:


Am 06.06.2015 um 17:59 schrieb Felix Schumacher:


Hi all,

to enable the SMPT Sampler to use a higher TLS version than
TLSv1 it
seems to be necessary to change the SSLContext.getInstance call in
TrustAllSSLSocketFactory from "TLS" to "TLSv1.2".



Any idea why? When I test java HTTP connectivity, then "TLS" is
able to
connect TLSv1.2 if the JVM is new enough end the server supports
it. "TLS"
in getInstance() is not very wel documented, but in general seems
to support
al TLS versions trying to use the newest one supported by both
sides.

There's also the possibility to set enabledProtocols() which does
not
support the string "TLS", but only the explicit protocol versions.
But even
without setting enabled protocols and just sticking to defaults,I
can get a
TLSv1.2 (HTTP) connection with Java 8 and e.g. a TLSv1 connection
with Java
6, both creating the SSLContext via getInstance("TLS").


I have done my tests using java 7. When I repeated them with java 8
(after I
wrote the text below), I got the same results, as you reported. So
it seems
to be a problem with java 7 only.



Is there a public SMTP server which can be used to observe the
problem you
see?


I have used a docker image (catatnight/postfix) with self signed
certs.
Instead of running it directly, I started a shell with it:

$ docker run -ti -p 587:587  -e maildomain=whatever.local -e
smtp_user=user:pwd -v "${PATH_TO_CERTS}":/etc/postfix/certs
catatnight/postfix /bin/bash

Inside the new prompt I used the install.sh script from the docker
image, so
that my keys get used and disabled every protocol except TLSv1.2:

root@abc...:/# /opt/install.sh
# Some message about missing dkim keys (can be ignored)
root@abc...:/# postconf -e 'smtpd_tls_mandatory_protocols=TLSv1.2'
root@abc...:/# service postfix start
# Message that postfix started

In another terminal I used openssl to connect to the server with
TLSv1.2
(success) and TLSv1.2 (no success) using:

$ openssl s_client -tls1_2 -starttls smtp -connect localhost:587
# ...
# ---
# 250 DSN
quit
$ openssl s_client -tls1_1 -starttls smtp -connect localhost:587
# ...
# ---
$

With this setup and the getInstance("TLS") I got no connection, while
getInstance("TLSv1.2") gave me a connection.

When I start the postfix server in its default configuration (every
protocol
allowed except SSLv2), JMeter is able to make a connection, but will
use
TLSv1 only.

This test was done on ubuntu 14.04 LTS with OpenJDK 1.7.0_79. And
after I
wrote this text I repeated the tests with Oracles java versions
1.7.0_80,
1.8.0_45 and 1.9.0-ea-b66 where java 8 and 9 successfully created a
connection with getInstance("TLS") and java 7 did not.

So it seems to be a problem with java 7 and getInstance("TLS") only.

Should we still add a system property to influence the selection of
the used
protocol?


It won't do any harm, and might help some users, so I suggest we add
the property.


Not that there's two knobs one can turn: the so called protocol used
in getInstance() which can be a real protocol, but also the token
"TLS", and the list or protocols passed to
SSLSocket.enabledProtocols(). The interaction between the two is not
well documented, but it might be better keeping protocol as TLS but
explicitely enabling protocols via enabledProtocols. The supported
protocols are available via getSupportedSSLParameters().getProtocols().


After reading a bit more and doing some testing I think I have found an
easier solution, which is probably the correct way to do it.

javamail has a property "mail.smtp.ssl.protocols" which takes a space
separated list of protocols, that can be used for a new connection. If I
set it to "SSLv3 TLSv1 TLSv1.1 TLSv1.2" then even my java 7 installation
will connect to a server that only supports TLSv1.2.

I don't have to change getInstance("TLS").


That makes sense to me. The Javadoc for that property says that the
values will be used in the call SSLSocket.setEnabledProtocols().

The only problem is if we use a protocol name in the list which is
actually not supported by the JVM version. That would result likely in
a java.lang.IllegalArgumentException: TLSv1.1.

Currently, since we want to demand Java 7, there's no difference
between the list for Java 7 and 8. The problem will show up sometime
in the future when TLS 1.3 becomes available. Maybe not important
enough for now. If you like you could instead use the list available
via SSLContext.getSupportedSSLParameters().getProtocols().

I have attached a patch which uses
SSLContext.getDefault().getSupported... this version connects with java
7 to my TLSv1.2 only postfix server.

Regards
  Felix


Regards,

Rainer

Re: Is the git repo still being synched?

[Rainer Jung]

Am 08.06.2015 um 12:12 schrieb sebb:

There are some other reports of Github issues:

INFRA-9783

INFRA-9778

INFRA-9785

I think these have all been resolved, if JMeter is still not synched,
then it would be best to raise a new INFRA issue.


It was synced sometime yesterday evening. But the situation was kind of 
unstable, even when jmeter was not in sync, other repos like httpd were. 
Infra has an idea what went wrong, but it is maye not 100% safe.


We should keep an eye on it and give infra feedback if the problem 
reappears.


Regards,

Rainer


On 7 June 2015 at 14:47, Rainer Jung  wrote:

Am 07.06.2015 um 15:38 schrieb Rainer Jung:


Am 07.06.2015 um 15:35 schrieb Milamber:



ASF svn US service has been migrate to a new host last friday, perhaps
something are wrong with Github/new config.

@sebb, do you know the process to synchronize with github or we need to
open ticket on Infra?



Github seems to sync from the ASF git repos, and the ASF git repos for
jmeter is also unchanged since Friday.

I will see if I can get a short comment from infra via chat whether it
is a known problem or not.



It seems currently noone can answer via chat (Sunday). It is known though
that the server migration on Friday didn't go well. I'll keep an eye on who
is hanging around and ask again later today, opening an issue if it seems
appropriate.

Regards,

Rainer

Re: svn commit: r1690395 - /jmeter/trunk/bin/templates/templates.xml

[Rainer Jung]

Is the second hunk intended? Just asking because that change isn't 
mentioned in the log message.


Regards,

Rainer

Am 11.07.2015 um 19:17 schrieb pmoua...@apache.org:

Author: pmouawad
Date: Sat Jul 11 17:17:26 2015
New Revision: 1690395

URL: http://svn.apache.org/r1690395
Log:
groovy has moved

Modified:
 jmeter/trunk/bin/templates/templates.xml

Modified: jmeter/trunk/bin/templates/templates.xml
URL: 
http://svn.apache.org/viewvc/jmeter/trunk/bin/templates/templates.xml?rev=1690395&r1=1690394&r2=1690395&view=diff
==
--- jmeter/trunk/bin/templates/templates.xml (original)
+++ jmeter/trunk/bin/templates/templates.xml Sat Jul 11 17:17:26 2015
@@ -82,7 +82,7 @@
  
  
+
+Building a JMS Topic (ActiveMQ) Publishing Test Plan
+/bin/templates/jmsPublishTemplate.jmx
+
+
  

Re: Documentation and more

[Rainer Jung]

Am 04.10.2015 um 16:48 schrieb Felix Schumacher:

Hi all,

I have spend a lot of time lately going through the docs for jmeter and
especially looking at the markup side of the documentation.

I have noticed a few things, that could be (hopefully) improved.


Thanks!


Code examples
-
The code examples are all treated as plain text. There is no further
markup to differentiate a shell script from an xml fragment or a java
source code example.

Maybe we could use a javascript library like
https://github.com/google/code-prettify? We would have to add an


The httpd project uses prettify since about 2 years and it does really 
improve readability of source code snippets and config examples in docs. 
The sources httpd uses are in


http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/style/scripts/


language attribute to each of our source code examples and extend the
style sheets.


In the httpd world a config snippet is for example contained in
...

Regards,

Rainer

Re: UBIKLOADPACK JSON PLUGIN DONATION TO APACHE JMETER

[Rainer Jung]

Am 14.10.2015 um 21:05 schrieb UBIK LOAD PACK Support:

Hello Dev Team,
I am contacting you to know if you would be interested in integrating our
JSON Plugin within Core JMeter.

Its features are shown on our blog, I didn't put any link because none of
my 2 previous mails were received on dev mailing list.


Currently plugin uses com.ubikingenierie.loadpack package, but it would be
donated with a package you would choose:

- org.apache.jmeter.json for example


If you are OK and wish to integrate it, we would submit a PR on Github so
that you can review it and potentially provide some patches before
integration in JMeter.
Your feedback is welcome.


We think this feature would be very useful for Web Application testing
where JSON format is becoming a very frequently used format for Rest
Webservices for example.


I would find it useful too. Agreed, that JSON for REST is a common 
pattern nowadays and handling JSON data as text via Regexp etc. is not 
adequate.


Hoping the link goes through, this is the original blog post about the 
plugin:


http://www.ubik-ingenierie.com/blog/easy-scripting-of-json-applications-with-apache-jmeter/

Regards,

Rainer

Re: [VOTE] Accept the donation of UBIKLOADPACK Json Plugin

[Rainer Jung]

Am 17.10.2015 um 10:08 schrieb Milamber:

Hello,

As stated in a previous thread [1], UbikLoadPack are proposing the
donation of their JSON Plugin [2].The code are submitted here [2].

I would like to call a vote, so that we have formal consensus on
accepting the code into the project. I suggest that it be accepted and
integrated with the core of JMeter (some adjustments need to do on the
initial donation to allow the test ant task to do executed successful).

The vote will remain open for at least 72 hours.

As this is a technical decision, committer and PMC votes are binding.


[X] +1 - Accept the donation
[ ] +/-0 - No strong opinion
[ ] -1 - Do not accept the donation


Thanks to UbikLoadPack for offering the contribution.

Regards,

Rainer

Re: What about releasing a 2.14 ?

[Rainer Jung]

Am 09.12.2015 um 23:17 schrieb Philippe Mouawad:

Hello,
We have a quite rich version now I think (more than 50 bugs/enhancements+ 2
major features) , what about releasing a new version ?


I ran into 57804 which is unfixed. It is about JMeter not reusing the 
SSL context if client certs are used. I don't know how to fix and client 
cert usage is not that common, but if you get hit by this, the highly 
increased handshake rate often kills your cpu resources. I had a look at 
it a few months ago, but the fix wasn't obvious to me. Any ideas around 
here?


Regards,

Rainer

Re: What about releasing a 2.14 ?

[Rainer Jung]

I hope later today.

Thanks for the fix in any case!

Regards,

Rainer

Am 29.12.2015 um 09:24 schrieb Philippe Mouawad:

Hi Rainer, all,
Anybody had a chance to review and test code ?

Thx

On Sunday, December 27, 2015, Philippe Mouawad 
wrote:


Hi Rainer,
I think I fixed with  Revision: 1721771 the bug
https://bz.apache.org/bugzilla/show_bug.cgi?id=57804.
Could you have a look and test.

Beside this, I notice a change in the logs in the NoClientCert test case
attached between 2.13 and 2.14, I cannot tell if it's a bug or regular.

If you compare nohup-2.14-pre-commit-1721771-no-client-cert.log with
nohup-2.13-no-client-cert.log.

With 2.13 I see only 1 time => *** ClientHello, TLSv1
With 2.14 I see 4 times => *** ClientHello, TLSv1, but preceded the 3 last
times with => %% Try resuming [Session-1,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA] from port 2571

Regards
Philippe M.
@philmdot

Re: svn commit: r1723203 - in /jmeter/trunk: bin/jmeter.properties src/core/org/apache/jmeter/JMeter.java src/core/org/apache/jmeter/reporters/Summariser.java

[Rainer Jung]

Doesn't that change need a change log entry?

It changes user visible behavior if one uses a customized 
jmeter.properties file. I know that using a user.properties is better 
for not having to merge changes after doing an upgrade, but our docs 
frequently only mention jmeter.properties and one can use -p to load it 
from a work directory instead of the distribution provided one. Not a 
good practice but now uncommon.


So I suggest adding something like

  If you are using a custom jmeter.properties file instead of the 
default one, make sure that you include "summariser.name=summary". 
Otherwise the summariser will no longer be enabled during non-GUI testing.


About the second part, the change from 30 secs to 180 secs. I agree, 
that it is part of reverting r1550536, but all releases of the last two 
years contained that new value. So again it is a change in behavior and 
should be part of the change log. But see also the review thread on 
r1723411.


Regards,

Rainer

Am 06.01.2016 um 01:33 schrieb s...@apache.org:

Author: sebb
Date: Wed Jan  6 00:33:49 2016
New Revision: 1723203

URL: http://svn.apache.org/viewvc?rev=1723203&view=rev
Log:
  Summariser should be enabled by default in Non GUI mode
  Revert the changes made in r1550536 and just enable via jmeter.properties
Bugzilla Id: 55512

Modified:
 jmeter/trunk/bin/jmeter.properties
 jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
 jmeter/trunk/src/core/org/apache/jmeter/reporters/Summariser.java

Modified: jmeter/trunk/bin/jmeter.properties
URL: 
http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.properties?rev=1723203&r1=1723202&r2=1723203&view=diff
==
--- jmeter/trunk/bin/jmeter.properties (original)
+++ jmeter/trunk/bin/jmeter.properties Wed Jan  6 00:33:49 2016
@@ -835,12 +835,13 @@ wmlParser.types=text/vnd.wap.wml
  # Summariser - Generate Summary Results - configuration (mainly applies to 
non-GUI mode)
  #---
  #
-# Define the following property to automatically start a summariser with that 
name
+# Comment the following property to disable the default non-GUI summariser
+# [or change the value to rename it]
  # (applies to non-GUI mode only)
-#summariser.name=summary
+summariser.name=summary
  #
-# interval between summaries (in seconds) default 30 seconds
-#summariser.interval=30
+# interval between summaries (in seconds) default 3 minutes
+#summariser.interval=180
  #
  # Write messages to log file
  #summariser.log=true

Modified: jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
URL: 
http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/jmeter/JMeter.java?rev=1723203&r1=1723202&r2=1723203&view=diff
==
--- jmeter/trunk/src/core/org/apache/jmeter/JMeter.java (original)
+++ jmeter/trunk/src/core/org/apache/jmeter/JMeter.java Wed Jan  6 00:33:49 2016
@@ -797,7 +797,7 @@ public class JMeter implements JMeterPlu
  convertSubTree(tree);

  Summariser summer = null;
-String summariserName = JMeterUtils.getPropDefault("summariser.name", 
"summary");//$NON-NLS-1$
+String summariserName = JMeterUtils.getPropDefault("summariser.name", 
"");//$NON-NLS-1$
  if (summariserName.length() > 0) {
  log.info("Creating summariser <" + summariserName + ">");
  println("Creating summariser <" + summariserName + ">");

Modified: jmeter/trunk/src/core/org/apache/jmeter/reporters/Summariser.java
URL: 
http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/jmeter/reporters/Summariser.java?rev=1723203&r1=1723202&r2=1723203&view=diff
==
--- jmeter/trunk/src/core/org/apache/jmeter/reporters/Summariser.java (original)
+++ jmeter/trunk/src/core/org/apache/jmeter/reporters/Summariser.java Wed Jan  
6 00:33:49 2016
@@ -71,8 +71,8 @@ public class Summariser extends Abstract

  private static final Logger log = LoggingManager.getLoggerForClass();

-/** interval between summaries (in seconds) default 30 seconds */
-private static final long INTERVAL = 
JMeterUtils.getPropDefault("summariser.interval", 30); //$NON-NLS-1$
+/** interval between summaries (in seconds) default 3 minutes */
+private static final long INTERVAL = 
JMeterUtils.getPropDefault("summariser.interval", 3 * 60); //$NON-NLS-1$

  /** Write messages to log file ? */
  private static final boolean TOLOG = 
JMeterUtils.getPropDefault("summariser.log", true); //$NON-NLS-1$

Re: svn commit: r1723411 - in /jmeter/trunk: bin/jmeter.properties src/core/org/apache/jmeter/reporters/Summariser.java

[Rainer Jung]

Am 07.01.2016 um 04:05 schrieb sebb:

On 6 January 2016 at 21:03,   wrote:

Author: pmouawad
Date: Wed Jan  6 21:03:36 2016
New Revision: 1723411

URL: http://svn.apache.org/viewvc?rev=1723411&view=rev
Log:
[Bug 55512] Summariser should be enabled by default in Non GUI mode
Restore 30 seconds as interval


-1

I don't agree with this for two reasons:
1) it's nothing to do with enabling the the Summariser, so would need
a different bugzilla (if agreed)


That change from 3 minutes to 30 seconds happened back in 
2013 and would have needed a different BZ by then. It was then released. 
One could thus argue, that your change from 30 seconds back to 3 minutes 
would have needed a BZ



2) The interval is far too short as a default; it will cause log files
to be much longer.


Since the value is configurable, it is a question about the best 
default. IMHO the best use case of the summariser is for human feedback 
during the test run. All other test analysis is better done based on the 
log protocol, reporting etc. For this live feedback I personally prefer 
a cycle where I don't have to wait so long. So I really liked the 30 
seconds and for me 3 minutes would be far too long.


Regards,

Rainer

Re: svn commit: r1779108 - in /jmeter/trunk: bin/jmeter bin/jmeter.bat xdocs/changes.xml

[Rainer Jung]

Hi there,

Am 16.01.2017 um 22:27 schrieb pmoua...@apache.org:

Author: pmouawad
Date: Mon Jan 16 21:27:21 2017
New Revision: 1779108

URL: http://svn.apache.org/viewvc?rev=1779108&view=rev
Log:
Bug 60593 - Switch to G1 GC algorithm
Bugzilla Id: 60593

Modified:
jmeter/trunk/bin/jmeter
jmeter/trunk/bin/jmeter.bat
jmeter/trunk/xdocs/changes.xml

Modified: jmeter/trunk/bin/jmeter
URL: 
http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter?rev=1779108&r1=1779107&r2=1779108&view=diff
==
--- jmeter/trunk/bin/jmeter (original)
+++ jmeter/trunk/bin/jmeter Mon Jan 16 21:27:21 2017
@@ -67,10 +67,7 @@ done

 PRGDIR=`dirname "$PRG"`

-# The following should be reasonably good values for most tests running
-# on Sun JVMs. Following is the analysis on which it is based. If it's total
-# gibberish to you, please study my article at
-# 
http://www.atg.com/portal/myatg/developer?paf_dm=full&paf_gear_id=1100010&detailArticle=true&id=9606
+#
 # Original page has disappeared, it is now only available at:
 # 
https://web.archive.org/web/20060614151434/http://www.atg.com/portal/myatg/developer?paf_dm=full&paf_gear_id=1100010&detailArticle=true&id=9606
 #
@@ -90,36 +87,18 @@ PRGDIR=`dirname "$PRG"`
 # system's memory availability:
 HEAP="-Xms512m -Xmx512m"

-# There's an awful lot of per-sample objects allocated during test run, so we
-# need a large eden to avoid too frequent scavenges -- you'll need to tune this
-# down proportionally if you modify the HEAP values above, below example is 
fine for 512m of Heap:
-# NEW="-XX:NewSize=128m -XX:MaxNewSize=128m"
-
-# This ratio and target have been proven OK in tests with a specially high
-# amount of per-sample objects (the HtmlParserHTMLParser tests):
-# SURVIVOR="-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50"
-
-# Think about it: trying to keep per-run objects in tenuring definitely
-# represents a cost, but where's the benefit? They won't disappear before
-# the test is over, and at that point we will no longer care about performance.
-#
-# So we will have JMeter do an explicit Full GC before starting a test run,
-# but then we won't make any effort (or spend any CPU) to keep objects
-# in tenuring longer than the life of per-sample objects -- which is hopefully
-# shorter than the period between two scavenges):
-#
-TENURING="-XX:MaxTenuringThreshold=2"
-
-CLASS_UNLOAD="-XX:+CMSClassUnloadingEnabled"
+#VERBOSE_GC="-verbose:gc -Xloggc:gc_jmeter_%p.log -XX:+PrintGCDetails 
-XX:+PrintGCCause -XX:+PrintTenuringDistribution -XX:+PrintHeapAtGC 
-XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime 
-XX:+PrintGCDateStamps"

 # Finally, some tracing to help in case things go astray:
-#DEBUG="-verbose:gc -XX:+PrintTenuringDistribution"
+GC_ALGO="-XX:+UseG1GC -XX:MaxGCPauseMillis=250 -XX:G1ReservePercent=20"
+
+CLASS_UNLOAD="-XX:+CMSClassUnloadingEnabled"


I think CMS class unloading doesn't make sense in combination with G1. 
CMS (concurrent Mark Sweep) is an alternative collector which can be 
used instead of G1. IMHO we should drop this variable ...



 # Always dump on OOM (does not cost anything unless triggered)
 DUMP="-XX:+HeapDumpOnOutOfMemoryError"

 SERVER="-server"

-ARGS="$SERVER $DUMP $HEAP $NEW $SURVIVOR $TENURING $PERM $CLASS_UNLOAD"
+ARGS="$SERVER $DUMP $HEAP $CLASS_UNLOAD $VERBOSE_GC $GC_ALGO"


... and remove it from ARGS


 java $ARGS $JVM_ARGS $JMETER_OPTS -jar "$PRGDIR/ApacheJMeter.jar" "$@"

Modified: jmeter/trunk/bin/jmeter.bat
URL: 
http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.bat?rev=1779108&r1=1779107&r2=1779108&view=diff
==
--- jmeter/trunk/bin/jmeter.bat (original)
+++ jmeter/trunk/bin/jmeter.bat Mon Jan 16 21:27:21 2017
@@ -71,31 +71,24 @@ rem On NT/2K grab all arguments at once
 set JMETER_CMD_LINE_ARGS=%*

 rem The following link describes the -XX options:
-rem 
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
-rem http://java.sun.com/developer/TechTips/2000/tt1222.html has some more 
descriptions
-rem Unfortunately TechTips no longer seem to be available, except via:
-rem 
https://web.archive.org/web/20090614101951/http://java.sun.com/developer/TechTips/2000/tt1222.html
+rem http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

 rem See the unix startup file for the rationale of the following parameters,
 rem including some tuning recommendations
 set HEAP=-Xms512m -Xmx512m
-set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
-set SURVIVOR=-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50%
-set TENURING=-XX:MaxTenuringThreshold=2
-rem Java 8 remove Permanent generation, don't settings the PermSize
-if %current_minor% LEQ "8" (
-rem Increase MaxPermSize if you use a lot of Javascript in your Test Plan :
-set PERM=-XX:PermSize=64m -XX:MaxPermSize=128m
-)
+
+#Uncomment this to generate GC verbose file
+rem set VERBOSE_GC=-verbose

Re: securerandom.source value change in Java 8 vs Java 7

[Rainer Jung]

Am 18.01.2017 um 17:54 schrieb Philippe Mouawad:

Hello,
Anybody knows why in  Java 8 on Mac OSX / Linux / Windows (but is it ) (at
least in last update but maybe in others)  version:

   - securerandom.source=file:/dev/random

While in last Java 7 version:

   - securerandom.source=file:/dev/urandom

From my experience this could have very bad performance on Linux servers
for example and could block.

Is it because something has changed in Java 8 ?
Reading the comments in java.security file, I don't see / understand what.

Thanks for any feedback.


Note that due to a JVM bug (I'm inclined to call it a bug) for Java up 
until version 7 although file:/dev/urandom is configured it will 
actually use file:/dev/randum (no "u"). That's why one typically finds 
the suggestion to use file:/dev/./urandom or file:/dev//urandom instead 
(any URL that is semantically equivalent to file:/dev/urandom but not 
stringwise identical will do).


For Java 8 the bug got fixed but the same time they changed the default 
maybe to not switch the effective default behavior. So now one again 
needs a non-default setting to ensure non-blocking behavior. For java 8, 
file:/dev/uranom will do, but the old workaround file:/dev/./urandom 
suggested for Java 7 will still do for Java 8.


Regards,

Rainer

Re: securerandom.source value change in Java 8 vs Java 7

[Rainer Jung]

Am 18.01.2017 um 22:56 schrieb Philippe Mouawad:

Hi Rainer,
Thanks a lot for your answer.

For reference the bug you mention is mentioned here:
http://security.stackexchange.com/questions/40633/java-
securerandom-doesnt-block-how

So if I understand you correctly, don't you think we should advise users of
JMeter to use /dev/urandom as we're switching to Java 8 and my
understanding is that it can introduce blocking behaviour ?


So for the forthcoming 3.2 since we only support it on Java 8 I'd say 
let's add


-Djava.security.egd=file:/dev/urandom

to the startup commandline in the start script. It looks less strange 
than the /dev/./urandom variant and it does solve the blocking problem 
for Java 8. Using real blocking randomness should not be necessary for 
JMeter.


If people ask for JMeter before 3.2 then the best advice would be to use

-Djava.security.egd=file:/dev/./urandom

because that will work independent of Java version.

Regards,

Rainer


On Wed, Jan 18, 2017 at 10:51 PM, Rainer Jung 
wrote:


Am 18.01.2017 um 17:54 schrieb Philippe Mouawad:


Hello,
Anybody knows why in  Java 8 on Mac OSX / Linux / Windows (but is it ) (at
least in last update but maybe in others)  version:

   - securerandom.source=file:/dev/random

While in last Java 7 version:

   - securerandom.source=file:/dev/urandom

From my experience this could have very bad performance on Linux servers
for example and could block.

Is it because something has changed in Java 8 ?
Reading the comments in java.security file, I don't see / understand what.

Thanks for any feedback.



Note that due to a JVM bug (I'm inclined to call it a bug) for Java up
until version 7 although file:/dev/urandom is configured it will actually
use file:/dev/randum (no "u"). That's why one typically finds the
suggestion to use file:/dev/./urandom or file:/dev//urandom instead (any
URL that is semantically equivalent to file:/dev/urandom but not stringwise
identical will do).

For Java 8 the bug got fixed but the same time they changed the default
maybe to not switch the effective default behavior. So now one again needs
a non-default setting to ensure non-blocking behavior. For java 8,
file:/dev/uranom will do, but the old workaround file:/dev/./urandom
suggested for Java 7 will still do for Java 8.

Regards,

Rainer

Re: buildbot failure in on jmeter-nightly

[Rainer Jung]

Am 14.02.2017 um 03:37 schrieb build...@apache.org:

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

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

Buildslave for this Build: bb_slave1_ubuntu

Build Reason: The Nightly scheduler named 'jmeterNightly' triggered this build
Build Source Stamp: [branch jmeter/trunk] HEAD
Blamelist:

BUILD FAILED: failed shell_5


The build fails when comparing CSV files:

1c1
< 
/home/buildslave/slave/jmeter-nightly/build/bin/testfiles/BatchTestLocal.csv

---
> /home/buildslave/slave/jmeter-nightly/build/bin/BatchTestLocal.csv
54,60c54,60
< Java If once 2,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
< Java If all 1,,,Thread Group 1-1,text,false,,0,1,1,null,,1,1
< Java OK,200,OK,Thread Group 1-1,text,true,,0,1,1,null,,1,0
< Java 1 C1=1,200,OK,Thread Group 1-2,text,true,,10,1,1,null,,1,0
< Java 1 C1=1,200,OK,Thread Group 1-2,text,true,,10,1,1,null,,1,0
< Java 1 C1=1,200,OK,Thread Group 1-2,text,true,,10,1,1,null,,1,0
< Loop5 C1=1 C2=1 C3=11,200,OK,Thread Group 1-2,text,true,,0,1,1,null,,1,0
---
> Java 1 C1=1,200,OK,Thread Group 1-2,text,true,,10,2,2,null,,1,0
> Java If once 2,200,OK,Thread Group 1-1,text,true,,0,2,2,null,,1,0
> Java 1 C1=1,200,OK,Thread Group 1-2,text,true,,10,2,2,null,,1,0
> Java 1 C1=1,200,OK,Thread Group 1-2,text,true,,10,2,2,null,,1,0
> Java If all 1,,,Thread Group 1-1,text,false,,0,2,2,null,,1,1
> Loop5 C1=1 C2=1 C3=11,200,OK,Thread Group 1-2,text,true,,0,2,2,null,,1,0
> Java OK,200,OK,Thread Group 1-1,text,true,,0,2,2,null,,1,0

The order is different and the first file does not have 2 threads in the 
differing block. Both files have only 1 thread before and after that 
block, but only one has 2 inside that block.


Regards,

Rainer

Re: [VOTE] Release JMeter 3.2 RC2

[Rainer Jung]

Am 01.04.2017 um 18:23 schrieb Milamber:

Hello,

The second release candidate for JMeter 3.2 (r1789808) 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 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.2RC2/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 8+.

Download - Archives/hashes/sigs:

https://dist.apache.org/repos/dist/dev/jmeter/v3.2_RC2/
(dist revision r18998)

RAT report:

http://home.apache.org/~milamber/jmeter-3.2RC2/dist/rat-report-jmeter-3.2RC2.txt


MD5 hashes of archives for this vote:

cfa8095f9c42208eb70caa6a0074558a *apache-jmeter-3.2.tgz
5d49a7cf94ce4dfebc68ab35f6f686d8 *apache-jmeter-3.2.zip
2dad5f6366647c93f822c87e64ff24ac *apache-jmeter-3.2_src.tgz
43f4ea27110efb23032e708e44dafe55 *apache-jmeter-3.2_src.zip

Site Docs are here:
http://home.apache.org/~milamber/jmeter-3.2RC2/docs/

Maven staging repository is accessible here:
https://repository.apache.org/content/repositories/orgapachejmeter-1016/org/apache/jmeter/


Tag:
https://svn.apache.org/repos/asf/jmeter/tags/v3_2_RC2/

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.2 requires Java 8 or later to run.

Some known issues and incompatible changes are listed on changes page.
http://home.apache.org/~milamber/jmeter-3.2RC2/docs/changes.html#Known%20problems%20and%20workarounds



All feedback and vote are welcome.

[XX] +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.


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!


+1 (binding), thanks for RM.

Details:

- MD5 OK
- signatures OK
- key in KEYS file
- tgz and zip for src and bin consistent
- svn and tgz/zip mostly consistent
  - file bin/utility.groovy missing in src tgz/zip
IMHO not a showstopper, fixed in r1789871 after RC2.
Note: the missing file breaks the ability to run
"ant distribution" from a src tgz/zip.
I think this must have already been the case for
3.1 (untested).
  - some files with name "*cp1252*" contain some binary differences
between svn and zip.
Example: file 
test/resources/org/apache/jmeter/protocol/jms/sampler/render/cp1252.txt

in svn is 3 bytes hex 0xe9 0xe8 0x80
and in zip 6 bytes hex 0xef 0xbf 0xbd 0xef 0xbf 0xbd
- files bin/report-template/*/*/*/make.sh are not executable
  (not in svn and not in any bin or src archive)
- builds fine except:
  - needed to disable class RenderInBrowser.java,
because Oracle doesn't support JavaFX for Solaris
- build result looks consistent with distribution, except for
  - some ordering in javadoc (expected)
  - binary jar files (expected)
- no Javadoc warnings
- new dependencies (expected)
- ran the tests (but only with java.awt.headless) without failures
  - needed to adjust the 500ms test execution time margin in
TestSchedulerWithTimer.jmx (slow test system)
- I have not checked the staging repository.
- I have not checked the rat report

Build and tests were done using Java 1.8.0_121, OS was Solaris 10 Sparc.

Regards,

Rainer

Re: [VOTE] Release JMeter 3.3 RC1 (with home.apache.org links)

[Rainer Jung]

Am 18.09.2017 um 07:59 schrieb Milamber:

Hello,

The first release candidate for JMeter 3.3 (r1808647) has been prepared,
and your votes are solicited.

...


[XX] +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 (binding) and thanks for RM!

Rainer