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:56:58 GMT
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 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 ?
Or it could be managed by all interruptible sampler as a common behaviour.
Not through timers but it's 2)

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