[GitHub] jmeter issue #358: Checkstyle: LineLength max 165, AnonInnerLength 45 and ot...

[ham1]

Github user ham1 commented on the issue:

https://github.com/apache/jmeter/pull/358
  
Sorry, yeah I see how this is difficult to review. I tend to change things 
as I see them in the file I'm editing. I will revise and split it up into one 
type of change per commit, is that ok? It might be more than 10 files but 
should be easier to review.


---

buildbot failure in on jmeter-nightly

[buildbot]

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/878

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

Buildslave for this Build: bb_1604_test_ubuntu

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

BUILD FAILED: failed shell_5

Sincerely,
 -The Buildbot

Jenkins build is back to normal : JMeter Windows #949

[Apache Jenkins Server]

See 

[GitHub] jmeter issue #231: WIP: timer that produces poisson arrivals with given cons...

[pmouawad]

Github user pmouawad commented on the issue:

https://github.com/apache/jmeter/pull/231
  
Hi @vlsi ,
Could you confirm your component implements the following features:
1) "Specific number of iterations per hour".
   The very basic requirement is to ensure you end up exactly 50
iterations per hour.
   Business customers would not understand if you report load test
results with 47 executions "just because the random was random".

   All timers except "Constant" can easily send excessive requests or
send less requests than required. There is no way to control it.

2) "Bursty load" simulation. There is no easy way to test "50
iterations per hour as 10 bursts of 5 items".

3) "Repeatable test profile". All the random timers produce different
pattern on each test run. This is not good for low-level analysis
(e.g. compare of CPU% charts, etc).

4) "Avoid all thread groups" to fire at 00:00:00. By default, all
thread groups would fire at 0, so there would be noticeable spike at
the start of the test.

Thanks


---

Build failed in Jenkins: JMeter Windows #948

[Apache Jenkins Server]

See 


Changes:

[pmouawad] Added finals to fields where possible
Contributed by Graham Russell
This closes #359

[pmouawad] Bug 61919 - UX : Reorder Menus
Reordered menus a bit differently
Make 100 the default value to be able to move some elements down
Bugzilla Id: 61919

[pmouawad] Bug 61920 - Plugins : Add ability to listen to Test Plan 
loading/closing
Contributed by  Peter Doornbosch
This closes #361
Bugzilla Id: 61920

[pmouawad] Drop mention of workbench

[pmouawad] Bug 61919 - UX : Reorder Menus
Contributed by Graham Russell
Reordered menus (3/3)
This closes #360
Bugzilla Id: 61919

[pmouawad] Bug 61919 - UX : Reorder Menus
Contributed by Graham Russell
Reordered menus (2/3)
This comment #360
Bugzilla Id: 61919

[pmouawad] Bug 61919 - UX : Reorder Menus
Contributed by Graham Russell
Reordered menus (1/3)
This comment #360
Bugzilla Id: 61919

[pmouawad] Bug 61919 - UX : Reorder Menus
Refactoring/formatting in preparation for alternate menu sorting
Contributed by Graham Russell
This closes #357
Bugzilla Id: 61919

--
[...truncated 171.90 KB...]
   [concat] at 
org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:45) 
~[mina-core-2.0.16.jar:?]
   [concat] at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:683)
 [mina-core-2.0.16.jar:?]
   [concat] at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:659)
 [mina-core-2.0.16.jar:?]
   [concat] at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:648)
 [mina-core-2.0.16.jar:?]
   [concat] at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:68)
 [mina-core-2.0.16.jar:?]
   [concat] at 
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1120)
 [mina-core-2.0.16.jar:?]
   [concat] at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) 
[mina-core-2.0.16.jar:?]
   [concat] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
[?:1.8.0_152]
   [concat] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
[?:1.8.0_152]
   [concat] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_152]
   [concat] 2017-12-20 10:19:33,506 ERROR TimeServerHandler: Exception occured
   [concat] java.io.IOException: An established connection was aborted by the 
software in your host machine
   [concat] at sun.nio.ch.SocketDispatcher.read0(Native Method) 
~[?:1.8.0_152]
   [concat] at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43) 
~[?:1.8.0_152]
   [concat] at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) 
~[?:1.8.0_152]
   [concat] at sun.nio.ch.IOUtil.read(IOUtil.java:197) ~[?:1.8.0_152]
   [concat] at 
sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) ~[?:1.8.0_152]
   [concat] at 
org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:317) 
~[mina-core-2.0.16.jar:?]
   [concat] at 
org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:45) 
~[mina-core-2.0.16.jar:?]
   [concat] at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:683)
 [mina-core-2.0.16.jar:?]
   [concat] at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:659)
 [mina-core-2.0.16.jar:?]
   [concat] at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:648)
 [mina-core-2.0.16.jar:?]
   [concat] at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:68)
 [mina-core-2.0.16.jar:?]
   [concat] at 
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1120)
 [mina-core-2.0.16.jar:?]
   [concat] at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) 
[mina-core-2.0.16.jar:?]
   [concat] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
[?:1.8.0_152]
   [concat] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
[?:1.8.0_152]
   [concat] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_152]
   [concat] 2017-12-20 10:19:33,535 WARN o.a.j.p.t.s.TCPSampler: Could not 
create socket for tcp://localhost:2223
   [concat] java.net.ConnectException: Connection refused: connect
   [concat] at java.net.DualStackPlainSocketImpl.waitForConnect(Native 
Method) ~[?:1.8.0_152]
   [concat] at 
java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85)
 ~[?:1.8.0_152]
   [concat] at 

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

[Apache Jenkins Server]

See 

[GitHub] jmeter issue #361: More hooks for testplan modifications

[ptrd]

Github user ptrd commented on the issue:

https://github.com/apache/jmeter/pull/361
  
Thanks Philippe.


---

[GitHub] jmeter issue #343: Reduced the size of all screenshots.

[pmouawad]

Github user pmouawad commented on the issue:

https://github.com/apache/jmeter/pull/343
  
Hi Team,
if there are volunteer to merge this one, thanks in advance.
Regards


---

[GitHub] jmeter issue #358: Checkstyle: LineLength max 165, AnonInnerLength 45 and ot...

[pmouawad]

Github user pmouawad commented on the issue:

https://github.com/apache/jmeter/pull/358
  
Hi @ham1 ,
Thanks for this PR.
Unfortunately I am not very comfortable with PR that touch a lot of file 
and where the code modification may touch more things than what the PR 
describes.

Would it be possible to rebase your PR and split it into at max 10 files ?
It is easier to review and merging is faster for me, which will mean I'll 
merge it earlier and you won't have to rebase.

Also if possible, try to make the PR really only touch what it pretends to.
Sonar fixes might sometimes break existing code so they need careful review 
and merge.
Thanks a lot again for all your work !

Regards


---

[GitHub] jmeter issue #356: Sonar fixes

[pmouawad]

Github user pmouawad commented on the issue:

https://github.com/apache/jmeter/pull/356
  
Hi @ham1 ,
Thanks for this PR.
Unfortunately I am not very comfortable with PR that touch a lot of file 
and where the code modification may touch more things than what the PR 
describes.

Would it be possible to rebase your PR and split it into at max 10 files ?
It is easier to review and merging is faster for me, which will mean I'll 
merge it earlier and you won't have to rebase.

Also if possible, try to make the PR really only touch what it pretends to.
Sonar fixes might sometimes break existing code so they need careful review 
and merge.
Thanks a lot again for all your work !

Regards


---

[GitHub] jmeter pull request #359: Added finals to fields where possible

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Menu item ordering

[Philippe Mouawad]

Hello Graham,
Thanks for  your ideas and contribution.
PRs merged , I like the new look .
I've reworked a bit the sort order to be able to move elements we will
possibly deprecated  at the bottom.

Regards

On Thu, Dec 14, 2017 at 1:59 PM, Graham Russell  wrote:

> I've submitted a PR (https://github.com/apache/jmeter/pull/360) for the
> menu re-ordering.
> Testing, critiques and any major disagreements with my proposed order very
> much welcomed!
>
> I've tried to keep it simple for the time being. We could add another item
> to the annotation, e.g. groups, which could then define more than the
> current (specifically ordered vs. the rest).
>
> The search box might take me a while, my swing GUI skills are lacking, and
> I might not get time before Christmas to work on it.
>
> I'm starting to like the idea of grouping plugins in their own sub-menu as
> this might make it more obvious for beginners and easier if you need a lot
> of plugins, then again, a palette with up to 10-15 things "ought to be
> enough for anybody".
>
> Thanks
>
> Graham
>
>
> On 12 December 2017 at 16:58, Vincent HERILIER 
> wrote:
> > Maybe could we propose different layouts (full flat (default ?), full
> > grouped, plugin only... defined by a property) mixed with LRU
> proposition,
> > Search box... accordingly to user preferences/habits/needs ?
> >
> >
> >
> > Le mar. 12 déc. 2017 à 16:40, Vincent HERILIER  a
> > écrit :
> >
> >> In the PR, I proposed, I grouped JMeter native elements as example, but
> >> the PR insured to let some elements at their initial place (JMEter ones
> to
> >> keep its current usability) and allow others to be grouped (3rd party
> ones
> >> if required and proposed by their related maintainers).
> >> So it was just allowing the feature, it didn't ordered it.
> >>
> >> Maybe it could be no more compatible with some evolutions you planned
> and
> >> that avoids it anyway.
> >> Or we could try to make these approaches complementary too...
> >>
> >> Anyway, I stay really interested in JMeter usability improvement.
> >>
> >> Le mar. 12 déc. 2017 à 16:15, Graham Russell  a
> écrit
> :
> >>
> >>> Ah, I didn't appreciate the use case you had.
> >>>
> >>> I still think the additional menu groupings would be detrimental to
> more
> >>> common use cases.
> >>>
> >>> Perhaps we can keep plugin menus ordered separated from the native ones
> >>> this might help slightly. I will make sure I test my changes with some
> >>> plugins!
> >>>
> >>> I was thinking to keep a LRU list in the search box results which
> should
> >>> speed things up for most use cases.
> >>>
> >>> Graham
> >>>
> >>>
> >>> On 12 December 2017 at 14:15, Vincent HERILIER 
> >>> wrote:
> >>> > I clearly understand your points of view.
> >>> >
> >>> > But with plugins used in my case (and average 300 testers) which
> bring
> >>> > average 40 config elements and 90 samplers, they are mixed (with
> JMeter
> >>> > native ones too) for complex and cross-protocol flows we would like
> to
> >>> > simulate (average 15 protocols - new , redefined protocols or server
> >>> side
> >>> > part - for our needs coverage).
> >>> >
> >>> > Reconfiguring a palette does not really solve my issue because the
> range
> >>> of
> >>> > required elements changes often or is wide each time.
> >>> > Loading and using a search box often will not really a gain of time
> too.
> >>> >
> >>> > That's why a protocol grouping is IMHO and in my specific use-case
> more
> >>> > accurate and quickly usable.
> >>> > I hope beiing wrong and I'm waiting for a quicker menu navigation
> >>> mechanism
> >>> > even it is not a submenu one ;).
> >>> >
> >>> > Thanks for all the work you provide to improve JMeter.
> >>> >
> >>> > Vincent
> >>> >
> >>> > Le mar. 12 déc. 2017 à 14:29, Graham Russell  a
> >>> écrit :
> >>> >
> >>> >> I agree with Phillipe that adding more menus, and therefore steps to
> >>> >> get to items you need (key presses or mouse moves) and items to read
> >>> >> is not an improvement.
> >>> >>
> >>> >> I like the idea of a configurable palette (with some sensible
> >>> >> defaults), much easier for beginners.
> >>> >>
> >>> >> This still requires use of the mouse, so for more advanced users,
> what
> >>> >> do we think of introducing a "find/search"?
> >>> >> Pressing ctrl+shift+a loads a pop-up search box, as you type it
> >>> >> filters the list and you click/press enter on the one you want and
> >>> >> it's added to the tree.
> >>> >>
> >>> >> On 12 December 2017 at 13:11, Philippe Mouawad
> >>> >>  wrote:
> >>> >> > Hello,
> >>> >> > I am personally against an additional level in the popup menu as
> it
> >>> would
> >>> >> > be a loss of time.
> >>> >> > If it's about reorganizing the menu order to put most popular ones
> on
> >>> >> top,
> >>> >> > why not.
> >>> >> >
> >>> >> > A configurable palette in the right or bottom 

Re: add hooks to JMeter for websocket plugin

[Philippe Mouawad]

Hello Peter,
Thanks for your ideas and PR which has been merged with slight
modifications.

Tests and feedback very welcome.
Regards
Philippe

On Sun, Dec 17, 2017 at 8:48 PM, Peter Doornbosch <
peter.doornbo...@gmail.com> wrote:

> Hi,
>
> In my JMeter websocket plugin (
> https://bitbucket.org/pjtr/jmeter-websocket-samplers) I want to hide
> advanced options for first time users. One of my design goals for this
> plugin was to make it very easy to use, so that first-time users are
> not overwhelmed with loads of options they don't know how to use and this
> will only confuse them. Up till now, i think i succeeded (but of course
> that's for others to judge ;-)).
>
> However, i'm now at the point that i need to add functionality that will
> only be used by advanced users. To keep the UI simple and clear for others,
> these advanced options must be explicitly enabled. Currently, this is done
> by setting a JMeter property. It works, but what i would like is that users
> can simply enable this (and other) option(s) by adding a special Config
> element in their test plan and enable/disable the options they want to use.
> This keeps the settings (e.g. whether options are enabled or not) in the
> testplan, which will avoid surprises when a testplan that relies on these
> features is being loaded in a JMeter instance that doesn't have the
> property set.
>
> I've been experimenting with this approach and i'm pretty happy with it.
> However, to make it work correctly, i need some extra hooks in JMeter.
>
> The proposed changes explained below, are committed to my JMeter fork at
> https://github.com/ptrd/jmeter/commits/more-hooks-for-
> testplan-modifications
> .
>
> Change 1
> See
> https://github.com/ptrd/jmeter/commit/a968db8bb63d16d6ea176ed00c0746
> 68958b7544
> A "removed" method is added to TestElement, so a test element can react on
> it being removed from the test plan.
> I need this for the functionality explained above, because when the user
> removes the special Configuration element that enables certain options,
> these options must be disabled.
>
> Change 2
> See
> https://github.com/ptrd/jmeter/commit/50e326ff824e231961308eed5185ae
> af2d894f60
> A "TestPlanListener" is added, and its "testPlanCleared" method is called
> when the test plan is clear.
> Similarly to change 1, when a testplan is closed and another one is loaded,
> i need a hook to reset the state of the advanced options.
> Of course, when included in JMeter, the TestPlanListener should probably be
> extended with some other methods to make it a consistent interface; for now
> i just wanted to create a working proof-of-concept.
>
> If you're interested in how these additions are used in the plugin, please
> see this branch:
> https://bitbucket.org/pjtr/jmeter-websocket-samplers/
> commits/branch/configure-options-in-testplan
> .
>
> Actually, i need one more feature, namely that a config element can be
> declared as "singleton" so it can't be added multiple times, but i haven't
> developed code for that yet - will follow later.
>
> I hope you are willing to add these hooks to JMeter, as, IMHO, these are
> generic hooks that can be useful for others and other use cases as well.
> For example, it has always frustrated me that the SSL keystore cannot be
> configured in a testplan; which such additions as proposed here, i think
> that would become possible too.
> Of course, if you have any thoughts about how the proposed changes can be
> improved, i'm happy to discuss it with you.
>
> Kind regards,
> Peter Doornbosch
>



-- 
Cordialement.
Philippe Mouawad.

buildbot success in on jmeter-trunk

[buildbot]

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

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] 1818757
Blamelist: pmouawad

Build succeeded!

Sincerely,
 -The Buildbot

buildbot failure in on jmeter-trunk

[buildbot]

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

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] 1818756
Blamelist: pmouawad

BUILD FAILED: failed shell_3

Sincerely,
 -The Buildbot