On 29 August 2015 at 16:56, Philippe Mouawad <[email protected]> wrote: > On Sat, Aug 29, 2015 at 5:34 PM, sebb <[email protected]> wrote: > >> On 29 August 2015 at 16:09, Philippe Mouawad <[email protected]> >> 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 <[email protected]> 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.
