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