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