jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Interrupt Timer design issue with multiple timers
Date Sat, 29 Aug 2015 15:34:52 GMT
On 29 August 2015 at 16:09, Philippe Mouawad <> wrote:
> 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.

There are two isses here:
1) is the functionality needed and useful?
2) is the implementation appropriate?

As to (1), there have been a few user requests as to how to implement
HTTP sample timeouts.
The answer has always been that one can only do timeouts for
individual low-level reads/writes.

Similar considerations apply to FTP and all the other samplers that
have a network element.

I think the only sampler that currently has an overall timeout is the
OS Sampler.

So if a test run hangs on a particular sampler, the only solution
currently is to stop the entire test.

Are you really saying that adding such sampler timeouts would not
improve JMeter usability?

Let's get that question out of the way first, and one can then deal
with the implementation if relevant.

> Regards
> Philippe
> On Sat, Aug 29, 2015 at 4:50 PM, sebb <> 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.

View raw message