jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Interrupt Timer design issue with multiple timers
Date Sat, 29 Aug 2015 15:09:32 GMT
Hi sebb,
Thanks for the implementation .
Looking at it and the initial requirement it looks to me it's over
engineering and complexity for a requirement that seems to me not that
frequent.

Looking at implementation of Interruption it looks to me a bit hard to use
and I dislike the fact that Timer feature is kind of "hacked" to do
something else.

There is already a frequent misconception about timers in that they run
before and all timers in scope are cumulated, this has been raised in the
past by Andrei in a thread.
If we add to this this special Timer which in fact is not at all, I am
afraid it will not improve JMeter usability.

Regards
Philippe


On Sat, Aug 29, 2015 at 4:50 PM, sebb <sebbaz@gmail.com> wrote:

> I've just realised that there is a problem with using a Timer for the
> Interrupt.
>
> If there are any other timers, JMeter will wait before starting the sample.
> However the interrupt timeout job is created when JMeter calls the
> Timers to add up all the delays.
>
> There does not seem to be any way to have the IT invoked after the
> delay and before the timers, nor can it find out the delay that will
> be used (it could allow for this if so).
>
> Note that Pre-Processors are called before Timers, so making it one
> would not help either.
>
> So I think there will have to be some help from the JMeterThread class.
>
> In theory one could use the sampleStarted method in the SampleListener
> interface, but this is not implemented by JMeter in the main engine.
>
> It would be simple enough to implement sampleStarted and
> sampleStopped, however there are some problems with doing so:
> 1) the sampleStarted method passes a SampleEvent but this does not
> contain a reference to the sampler. However the TestElement could get
> the sampler from the context.
>
> 2) Adding calls to these new methods may slow down processing, as lots
> of classes implement the SamplerListener interface but don't actually
> use anything apart from sampleOccurred.
>
> As far as the Interrupt Timer is concerned, the simplest would be to
> add a new interface that is invoked just before the sampler is
> invoked. It would also be useful to call the IT just afterwards so it
> could remove the timer.
>
> But is that too much of a special case hack?
>



-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message