jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Interrupt Timer design issue with multiple timers
Date Sat, 29 Aug 2015 16:26:25 GMT
On 29 August 2015 at 16:56, Philippe Mouawad <philippe.mouawad@gmail.com> wrote:
> On Sat, Aug 29, 2015 at 5:34 PM, sebb <sebbaz@gmail.com> wrote:
>
>> On 29 August 2015 at 16:09, Philippe Mouawad <philippe.mouawad@gmail.com>
>> 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.
>>
> Can you point me to those where the provided answer based on putting low
> level timeout did not fit  ?

The most recent one is:
http://mail-archives.apache.org/mod_mbox/jmeter-user/201508.mbox/%3CCAKUYAYdrHq7YiRzK3wto7200K8VkhVZK4Joe3-FsKE%2BUXQj26Q%40mail.gmail.com%3E

I'm pretty sure there were others.

>
>> 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.
>>
> Can't we add a timeout to FTP also ?

That would only work for the network requests, unless we implemented
overall sample timeouts as well.
And what about TCP? etc.

> Or it could be managed by all interruptible sampler as a common behaviour.

That is what my Implementation is intended to do.

> Not through timers but it's 2)

Agreed.

But can we first agree that the functionality is useful?

>>
>> 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.
>>
> Unless you set a timeout, no ?
>
>>
>> Are you really saying that adding such sampler timeouts would not
>> improve JMeter usability?
>>
> If it's part of Samplers yes, if it's part of timers it is more confusing
> than helping in my opinion.
> A Timer has 1 purpose, which is to pause. In this particular case Interrupt
> Timer is not doing this.
>
>>
>> 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 <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.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Mime
View raw message