Timer adjustment feature / Bug 60018 (was Thoughts on 2 proposals)

[Philippe Mouawad <p....@ubik-ingenierie.com>]

Hello,
We provided a first patch so that discussion can continue on a concrete
basis:
- https://bz.apache.org/bugzilla/show_bug.cgi?id=60018

Patch makes the feature operational already, configuration is done through
property "timer.factor".



If you agree with it, we can continue implementing the rest:
- Update GUI to add checkbox for Timer that are adjustable. This checkbox
lets user decide if he refuse to apply the factor. "Accept Timer
adjustement" (checked by default)
- Add a new Configuration Element for Timer

Regards
UbikLoadPack Team

Re: Timer adjustment feature / Bug 60018 (was Thoughts on 2 proposals)

[Philippe Mouawad <ph...@gmail.com>]

Hello,
I commited a change on this by introducing ModifiableTimer:

   - [Bug 60018] Timer : Add a factor to apply on pauses


For now, I only registered Gaussian, Poisson and Uniform Timers as
implementing it so that to avoid any side effects to 3rd parties.

This will be the first step for this feature.
Once we migrate to Java8, It'll be enhanced to:

   - Add the Optional method
   - Add a field on the concerned timers GUI
   - Add a potential configuration elements to control this feature

Regards

Philippe



On Sat, Sep 3, 2016 at 12:37 PM, Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:

> Philippe>Frankly I doubt it. At least the platforms usually used for Load
> Testing
> Philippe>don't have the same constraints as those running J2EE Server can
> have.
>
> Exactly.
> I might be wrong, but I do not remember "-1" responses for moving to Java
> 8.
>
> Philippe>Well since there was no abstract class, I don't see.
> Philippe>Do you have other ideas ?
>
> One of the common patterns is "interface Timer2", so each timer opts-in and
> declares if it should be adjusted by default. The relevant JMeter core code
> would do an instanceof check.
> Naming is one of the hardest problems in computer science (it comes next
> after "cache invalidation"), so feel free to invent the best name for
> Timer2.
>
> Don't get me wrong, my best name for Timer2 is Java 8 :)
>
> Philippe>PS : Any chance that you submit your Constant Throughput timer
> Philippe>alternative patch ?
>
> Not sure. There might be legals issue.
>
> Vladimir
>



-- 
Cordialement.
Philippe Mouawad.

Re: Timer adjustment feature / Bug 60018 (was Thoughts on 2 proposals)

[Vladimir Sitnikov <si...@gmail.com>]

Philippe>Frankly I doubt it. At least the platforms usually used for Load
Testing
Philippe>don't have the same constraints as those running J2EE Server can
have.

Exactly.
I might be wrong, but I do not remember "-1" responses for moving to Java 8.

Philippe>Well since there was no abstract class, I don't see.
Philippe>Do you have other ideas ?

One of the common patterns is "interface Timer2", so each timer opts-in and
declares if it should be adjusted by default. The relevant JMeter core code
would do an instanceof check.
Naming is one of the hardest problems in computer science (it comes next
after "cache invalidation"), so feel free to invent the best name for
Timer2.

Don't get me wrong, my best name for Timer2 is Java 8 :)

Philippe>PS : Any chance that you submit your Constant Throughput timer
Philippe>alternative patch ?

Not sure. There might be legals issue.

Vladimir

Re: Timer adjustment feature / Bug 60018 (was Thoughts on 2 proposals)

[Philippe Mouawad <ph...@gmail.com>]

On Sat, Sep 3, 2016 at 11:12 AM, Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:

> Philippe>Could we consider introducing Java 8 in immediate next version for
> this feature ?
>
> As you know, I'm all ears for migrating to Java 8.
>
> I'm pretty sure this particular issue of "adding behavior to timers without
> breaking compatibility with previous third-party timers" could be solved
> with plain Java 7.
>

Well since there was no abstract class, I don't see.
We could reserve this behaviour to RandomTimer subclasses, this way we
wouldn't break backward compatibility.
Constant Timer would not be affected, that may be ok , as I suppose
constant is intended so maybe it should not be affected
As for The scriptable Timers (BSF, JSR223 and Beanshell) , we could leave
them as is, or introduce a helper method in JMeterUtils.

Do you have other ideas ?

I just highlight one of the cases where Java 8 shines, so the "backward
> compatibility dance" is much simpler there.
>
> Philippe>What are the risks of moving to Java8(without immediately using
> all the
> Philippe>syntactic sugar ) ?
>
> Technically speaking, we might want to make a poll on jmeter-users list.
> For instance, certain platforms might miss Java 8 runtime. I've no idea if
> there are lots of platforms that miss Java 8 and run JMeter at the same
> time.
>
Frankly I doubt it. At least the platforms usually used for Load Testing
don't have the same constraints as those running J2EE Server can have.

PS : Any chance that you submit your Constant Throughput timer alternative
patch ?


>
> Vladimir
>



-- 
Cordialement.
Philippe Mouawad.

Re: Timer adjustment feature / Bug 60018 (was Thoughts on 2 proposals)

[Vladimir Sitnikov <si...@gmail.com>]

Philippe>Could we consider introducing Java 8 in immediate next version for
this feature ?

As you know, I'm all ears for migrating to Java 8.

I'm pretty sure this particular issue of "adding behavior to timers without
breaking compatibility with previous third-party timers" could be solved
with plain Java 7.
I just highlight one of the cases where Java 8 shines, so the "backward
compatibility dance" is much simpler there.

Philippe>What are the risks of moving to Java8(without immediately using
all the
Philippe>syntactic sugar ) ?

Technically speaking, we might want to make a poll on jmeter-users list.
For instance, certain platforms might miss Java 8 runtime. I've no idea if
there are lots of platforms that miss Java 8 and run JMeter at the same
time.

Vladimir

Re: Timer adjustment feature / Bug 60018 (was Thoughts on 2 proposals)

[Philippe Mouawad <p....@ubik-ingenierie.com>]

Hi Vladimir,
Could we consider introducing Java 8 in immediate next version for this
feature ?
This would also allow to introduce the Renderer based on Java 8 Web browser
in this version.

Initially it was delayed to N+2 version but it's maybe an opportunity to
move faster to java 8.

What are the risks of moving to Java8(without immediately using all the
syntactic sugar ) ?


Regards




On Saturday, September 3, 2016, Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:

> I'am afraid, adding a method to Timer interface is NOT a backward
> compatible change.
> What happens is you basically break all the third party timers and force
> to recompile ‎third party timers otherwise they do not implement the new
> method.
>
> Can you implement the feature so it is compatible with existing third
> party timers?
>
>
> PS Does it make sense to run "JMeter plugins tests" along with regular
> jmeter tests so we catch those "backward incompatible" warnings‎ early?
>
> PPS java 8's default methods on interfaces are watching you)
>
> Vladimir
>
>
>

-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>

UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>

Re: Timer adjustment feature / Bug 60018 (was Thoughts on 2 proposals)

[Vladimir Sitnikov <si...@gmail.com>]

I'am afraid, adding a method to Timer interface is NOT a backward compatible change.
What happens is you basically break all the third party timers and force to recompile ‎third party timers otherwise they do not implement the new method.

Can you implement the feature so it is compatible with existing third party timers?


PS Does it make sense to run "JMeter plugins tests" along with regular jmeter tests so we catch those "backward incompatible" warnings‎ early?

PPS java 8's default methods on interfaces are watching you)

Vladimir