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 Sun, 30 Aug 2015 06:46:06 GMT
On Sunday, August 30, 2015, sebb <sebbaz@gmail.com> wrote:

> On 29 August 2015 at 22:57, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;>> 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 ...
>
>  I know and  thanks for your work. I am trying in discussion to find the
best way to introduce this feature.

Note sebb that in the past you made me throw away 2 times huge parts of
code under the consideration that feature was out of scope or too complex:
- Redis Dataset (I contributed it to Jmeter-plugins in the end)
- The initial graphite listener. Hopefully this one was reworked hugely and
finally introduced as BackendListener.

So let's find a way to not loose your work and at the same time have a self
describing feature that scale.

Still I think you should be giving your opinion on JMeter RoadMap and maybe
start a new thread for 2015/2016.

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

I bumped again today so that you can see the mail.

>
> > 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.

in progress

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


-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message