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 22:33:14 GMT
On 29 August 2015 at 22:57, Philippe Mouawad <philippe.mouawad@gmail.com> wrote:
> Functionality is useful but it may introduce confusion :
> Cons:
> - http timeout vs http request timeout ( the one you want to introduce),
> users may be confused.

That's just a matter of good documentation.

> - it will make code more complex

Not much, but that depends partly on the exact implementation.

> Pros:
> + : it would allow to introduce timeout whenever sampler implements
> interruptible
>
> So it's useful but is it the priority compared to what we have in the
> RoadMap for example (see dev mailing list thread) ?

I've already done a lot of the work, so ...

What is in the RoadMap?
Please (re)start as a separate  thread for this as I don't recall any
recent discussion of it.

> Regarding 2), we shouldn't trigger a thread per timeout.
> If we do it we should have 1 thread timeouter and sampler register to it
> anytime the want to be timeouted.
> Current implementation will not scale.

Let's discuss that in another thread.

> On Saturday, August 29, 2015, sebb <sebbaz@gmail.com> wrote:
>
>> On 29 August 2015 at 16:56, Philippe Mouawad <philippe.mouawad@gmail.com
>> <javascript:;>> wrote:
>> > On Sat, Aug 29, 2015 at 5:34 PM, sebb <sebbaz@gmail.com <javascript:;>>
>> wrote:
>> >
>> >> On 29 August 2015 at 16:09, Philippe Mouawad <
>> philippe.mouawad@gmail.com <javascript:;>>
>> >> 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
>> <javascript:;>> 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.
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Mime
View raw message