buildbot success in on jmeter-nightly

2018-03-31 Thread buildbot
The Buildbot has detected a restored build on builder jmeter-nightly while 
building . Full details are available at:
https://ci.apache.org/builders/jmeter-nightly/builds/996

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

Buildslave for this Build: bb_slave7_ubuntu

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

Build succeeded!

Sincerely,
 -The Buildbot





[GitHub] jmeter issue #380: Hdrhistogram

2018-03-31 Thread pmouawad
Github user pmouawad commented on the issue:

https://github.com/apache/jmeter/pull/380
  
Hello,
Thanks @FSchumacher , looks like a good start.
@vlsi , looks interesting .
Can you help on integrating it ?

Thanks


---


[GitHub] jmeter issue #380: Hdrhistogram

2018-03-31 Thread vlsi
Github user vlsi commented on the issue:

https://github.com/apache/jmeter/pull/380
  
@FSchumacher , what do you think of 
https://github.com/LatencyUtils/LatencyUtils/ ?


---


[GitHub] jmeter pull request #380: Hdrhistogram

2018-03-31 Thread FSchumacher
GitHub user FSchumacher opened a pull request:

https://github.com/apache/jmeter/pull/380

Hdrhistogram

## Description


First try to replace percentile calculations with HdrHistogram.
This is just to get an impression, what we can gain by using another 
implementation and should not  be incorporated yet.

## Motivation and Context


Currently we have two different algorithms for calculating percentiles. The 
results differ and the algorithm is not documented. This should be changed 
(although it is not addressed yet by this pr).

Another point is the efficiency of the used algorithms. As the swing gui 
will be refreshed every 300 ms (or so), when data arrives and the mean, average 
and other percentiles are re-caculated on every refresh, the used algorithm 
should be very efficient. The currently used one is iterating over every bucket 
to calculate the mean (and std deviation).

The proposed implementation uses a different approach and doesn't need to 
iterate to calculate the mean, etc. The percentiles are calculated by 
HdrHistogram and the locking has been simplified by transferring all logic that 
modifies the data into the awt thread.

In my tests the samples per second went up from 200 per second over 1.400 
per second.

## How Has This Been Tested?




Tested by using a simple JSR223 Sampler that slept a bit (and by a JSR223 
Sampler, that pretended to sleep a bit)

## Screenshots (if appropriate):

## Types of changes

- Bug fix (non-breaking change which fixes an issue)
- New feature (non-breaking change which adds functionality)
- Breaking change (fix or feature that would cause existing functionality 
to not work as expected)

A bit of everything

## Checklist:


- [ ] My code follows the [code style][style-guide] of this project.
- [ ] I have updated the documentation accordingly.

[style-guide]: https://wiki.apache.org/jmeter/CodeStyleGuidelines


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/FSchumacher/jmeter hdrhistogram

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jmeter/pull/380.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #380


commit 4280996464a4adbed427672f7c6f0eda82c020e1
Author: fschumacher 
Date:   2018-03-30T17:17:19Z

HdrHistogram, first try

commit 492a869b705d36d6421d42899fdc73a2d052b88c
Author: fschumacher 
Date:   2018-03-31T07:05:19Z

Use more efficient algorithm to calculate mean and stddev




---


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

2018-03-31 Thread Apache Jenkins Server
See 




buildbot success in on jmeter-trunk

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

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

Buildslave for this Build: bb_slave1_ubuntu

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

Build succeeded!

Sincerely,
 -The Buildbot





Build failed in Jenkins: JMeter-trunk #6731

2018-03-31 Thread Apache Jenkins Server
See 


Changes:

[pmouawad] Bug 62238 - Add ability to Switch to next iteration of Current Loop
Drop unused labels
Bugzilla Id: 62238

[pmouawad] Bug 62238 - Add ability to Switch to next iteration of Current Loop
Add missing French labels
Bugzilla Id: 62238

--
[...truncated 171.54 KB...]
   [jmeter] Created the tree successfully using testfiles/BatchTestLocal.jmx
   [jmeter] Starting the test @ Sat Mar 31 12:00:19 UTC 2018 (1522497619166)
   [jmeter] Waiting for possible Shutdown/StopTestNow/Heapdump message on port 
4445
   [jmeter] summary + 55 in 00:00:40 =1.4/s Avg:   131 Min:13 Max:  
 249 Err: 8 (14.55%) Active: 1 Started: 2 Finished: 1
   [jmeter] summary + 78 in 00:00:08 =9.6/s Avg:   100 Min: 1 Max:  
 252 Err: 8 (10.26%) Active: 0 Started: 1 Finished: 1
   [jmeter] summary =133 in 00:00:49 =2.7/s Avg:   113 Min: 1 Max:  
 252 Err:16 (12.03%)
   [jmeter] Tidying up ...@ Sat Mar 31 12:01:08 UTC 2018 (1522497668396)
   [jmeter] ... end of run
 [echo] BatchTestLocal output files compared OK

batchtestserver:
   [server] SLF4J: Class path contains multiple SLF4J bindings.
   [server] SLF4J: Found binding in 
[jar:
   [server] SLF4J: Found binding in 
[jar:
   [server] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an 
explanation.
   [server] SLF4J: Actual binding is of type 
[org.apache.logging.slf4j.Log4jLoggerFactory]

batchtest:
 [echo] Starting BatchTestLocal with file BatchTestLocal.jmx using 
-Rasf935.gq1.ygridcore.net:2793 -Jdummy=dummy
   [server] Created remote object: UnicastServerRef2 [liveRef: 
[endpoint:[67.195.81.176:45822,SSLRMIServerSocketFactory(host=asf935.gq1.ygridcore.net/67.195.81.176,
 keyStoreLocation=rmi_keystore.jks, type=JKS, 
trustStoreLocation=rmi_keystore.jks, type=JKS, 
alias=rmi),SSLRMIClientSocketFactory(keyStoreLocation=rmi_keystore.jks, 
type=JKS, trustStoreLocation=rmi_keystore.jks, type=JKS, 
alias=rmi)](local),objID:[-7946b969:1627beece21:-7fff, 6283488841507732734]]]
   [client] SLF4J: Class path contains multiple SLF4J bindings.
   [client] SLF4J: Found binding in 
[jar:
   [client] SLF4J: Found binding in 
[jar:
   [client] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an 
explanation.
   [client] SLF4J: Actual binding is of type 
[org.apache.logging.slf4j.Log4jLoggerFactory]
   [client] Creating summariser 
   [client] Created the tree successfully using testfiles/BatchTestLocal.jmx
   [client] Configuring remote engine: asf935.gq1.ygridcore.net:2793
   [client] Starting remote engines
   [client] Starting the test @ Sat Mar 31 12:01:15 UTC 2018 (1522497675012)
   [server] Starting the test on host asf935.gq1.ygridcore.net:2793 @ Sat Mar 
31 12:01:18 UTC 2018 (1522497678590)
   [client] Remote engines have been started
   [client] Waiting for possible Shutdown/StopTestNow/Heapdump message on port 
4445
   [client] summary + 55 in 00:00:41 =1.3/s Avg:   107 Min: 3 Max:  
 224 Err: 8 (14.55%) Active: 1 Started: 3 Finished: 2
   [server] Finished the test on host asf935.gq1.ygridcore.net:2793 @ Sat Mar 
31 12:02:10 UTC 2018 (1522497730596) - exit requested.
   [client] summary + 78 in 00:00:10 =7.4/s Avg:   115 Min: 1 Max:  
 255 Err: 8 (10.26%) Active: 0 Started: 11 Finished: 11
   [client] summary =133 in 00:00:51 =2.6/s Avg:   112 Min: 1 Max:  
 255 Err:16 (12.03%)
   [client] Tidying up remote @ Sat Mar 31 12:02:10 UTC 2018 (1522497730596)
   [client] ... end of run
 [echo] BatchTestLocal output files compared OK

batch_scripts:

batchtest:
 [echo] Starting HTMLParserTestFile_2 with file HTMLParserTestFile_2.jmx 
using -X -Jdummy=dummy
   [jmeter] SLF4J: Class path contains multiple SLF4J bindings.
   [jmeter] SLF4J: Found binding in 
[jar:
   [jmeter] SLF4J: Found binding in 
[jar:
   [jmeter] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an 
explanation.
   [jmeter] SLF4J: Actual binding is of type 
[org.apache.logging.slf4j.Log4jLoggerFactory]
   [jmeter] Creating summariser 
   [jmeter] Created the tree successfully 

Build failed in Jenkins: JMeter-trunk #6730

2018-03-31 Thread Apache Jenkins Server
See 


Changes:

[pmouawad] Bug 62238 - Add ability to Switch to next iteration of Current Loop
Contributed by Ubik Load Pack
Bugzilla Id: 62238

[pmouawad] Bug 62237 - While Controller : Export variable containing current 
index of iteration
Add FIXME for code to be completed
Bugzilla Id: 62237

[pmouawad] Bug 62237 - While Controller : Export variable containing current 
index of iteration
Contributed by Ubik Load Pack
Bugzilla Id: 62237

--
[...truncated 165.77 KB...]
 [java] localhost/127.0.0.1
 [java] isSiteLocalAddress:false
 [java] isAnyLocalAddress:false
 [java] isLinkLocalAddress:false
 [java] isLoopbackAddress:true
 [java] isMulticastAddress:false
 [java] 
 [java] asf929.gq1.ygridcore.net/67.195.81.179
 [java] isSiteLocalAddress:false
 [java] isAnyLocalAddress:false
 [java] isLinkLocalAddress:false
 [java] isLoopbackAddress:false
 [java] isMulticastAddress:false
 [java] Interfaces: {name:vethaca1ec1 (vethaca1ec1) => 
[/fe80:0:0:0:e4d5:94ff:fe0c:2ed2%vethaca1ec1/64 [null]], name:docker0 (docker0) 
=> [/fe80:0:0:0:42:e5ff:fe42:7ab2%docker0/64 [null], /172.17.0.1/16 
[/0.0.0.0]], name:enp5s0f0 (enp5s0f0) => 
[/fe80:0:0:0:28c:faff:fe5b:40f4%enp5s0f0/64 [null], /67.195.81.179/26 
[/67.195.81.191]], name:lo (lo) => [/0:0:0:0:0:0:0:1%lo/128 [null], 
/127.0.0.1/8 [null]]}
 [java] java.rmi.server.hostname=null
 [java] Security framework of XStream not initialized, XStream is probably 
vulnerable.
 [java] Security framework of XStream not initialized, XStream is probably 
vulnerable.
 [java] Security framework of XStream not initialized, XStream is probably 
vulnerable.
 [java] Security framework of XStream not initialized, XStream is probably 
vulnerable.
 [java] 
../org/apache/jmeter/resources/messages_fr
 has unexpected key: test_action_action
 [java] E/org/apache/jmeter/resources/messages_pt_BR has unexpected 
key: test_action_action
 [java] E./org/apache/jmeter/resources/messages_es has unexpected key: 
test_action_action
 [java] E./org/apache/jmeter/resources/messages_tr has unexpected key: 
test_action_action
 [java] E.../org/apache/jmeter/resources/messages_zh_TW has unexpected key: 
test_action_action
 [java] 
E...Ignoring
 missing junit_failure_default_code=0001 in 
org/apache/jmeter/resources/messages_fr.properties
 [java] Ignoring missing aggregate_report_90=90% in 
org/apache/jmeter/resources/messages_fr.properties
 [java] Ignoring missing junit_error_default_code= in 
org/apache/jmeter/resources/messages_fr.properties
 [java] Ignoring missing junit_success_default_code=1000 in 

Re: TestAction: Change its name to make it more meaningful

2018-03-31 Thread Andrey Pokhilko
Hi,

"Test" sounds redundant to me. Everything we do in JMeter is a test. So
maybe just "Logical Action"?

--

Andrey Pokhilko

30.03.2018 18:15, UBIK LOAD PACK Support пишет:
> Hello,
>
> TestAction in JMeter is a very useful element but its name is misleading or
> not clear at all.
>
> Currently it allows:
>
>- Pausing
>- Stopping Test
>- Stopping Test immediately
>- Switching to next thread loop iteration
>- We'll soon propose a patch to add:
>   - Switch to next iteration of current loop : : It will be equivalent
>   of "continue" in the the first parent loop that contains it
>   - Break current loop : It will break the first parent loop that
>   contains it, equivalent of "break" in algorithm
>
>
> When we provide training or discuss with JMeter beginners, TestAction is
> usually understood as something to debug or "test", and nobody thinks that
> is allows all this.
>
> Shouldn't it be renamed to something like:
>
>- Test Logic Action
>- Logical Action
>- Test Logical Action
>- Test Execution Modifier
>
>
>
> Regards
> UbikLoadPack Support Team
> 
>