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 21:57:14 GMT
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.
- it will make code more complex

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) ?

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.

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message