You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by sebb <se...@gmail.com> on 2015/08/29 16:50:37 UTC
Interrupt Timer design issue with multiple timers
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?
Re: Interrupt Timer design issue with multiple timers
Posted by Philippe Mouawad <ph...@gmail.com>.
On Sunday, August 30, 2015, sebb <se...@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.
Re: Interrupt Timer design issue with multiple timers
Posted by sebb <se...@gmail.com>.
On 29 August 2015 at 22:57, Philippe Mouawad <ph...@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 <se...@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.
Re: Interrupt Timer design issue with multiple timers
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <se...@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.
Re: Interrupt Timer design issue with multiple timers
Posted by sebb <se...@gmail.com>.
On 29 August 2015 at 16:56, Philippe Mouawad <ph...@gmail.com> wrote:
> On Sat, Aug 29, 2015 at 5:34 PM, sebb <se...@gmail.com> wrote:
>
>> On 29 August 2015 at 16:09, Philippe Mouawad <ph...@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 <se...@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.
Re: Interrupt Timer design issue with multiple timers
Posted by Philippe Mouawad <ph...@gmail.com>.
On Sat, Aug 29, 2015 at 5:34 PM, sebb <se...@gmail.com> wrote:
> On 29 August 2015 at 16:09, Philippe Mouawad <ph...@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 <se...@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.
Re: Interrupt Timer design issue with multiple timers
Posted by sebb <se...@gmail.com>.
On 29 August 2015 at 16:09, Philippe Mouawad <ph...@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.
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.
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.
Are you really saying that adding such sampler timeouts would not
improve JMeter usability?
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 <se...@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.
Re: Interrupt Timer design issue with multiple timers
Posted by Philippe Mouawad <ph...@gmail.com>.
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.
Regards
Philippe
On Sat, Aug 29, 2015 at 4:50 PM, sebb <se...@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.