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: Design of Timeout test element / sampler interrupter
Date Sun, 30 Aug 2015 06:12:17 GMT
On Sunday, August 30, 2015, sebb <sebbaz@gmail.com> wrote:

> I've had a look at the classes that implement SampleListener, and
> apart from ResultAction and TransactionSampler, only the Listeners use
> it. Since usage of these should be minimised in a production test,
> it's likely that there won't be as many implementations as I had
> feard.

Implementation of SampleListener ?
Usage of which should be minimised ?  SampleListener ?

>
> Also if the implementation is empty, the overhead will be quite small.
>
> [There is a work-round if it does prove expensive: the SampleListener
> interface could be split into two parent interfaces.]
>
> So assuming that JMeterThread implements sampleStarted/sampleStopped,
> the Timeout element can use the Start to set up the timer and the Stop
> to cancel it. This will reduce the number outstanding as much as
> possible.
>
> The timeouts have to be implemented using separate threads for two reasons:
> - it's obviously not possible to interrupt a sampler from the same
> thread as the sampler
> - depending on the sampler, and its state, the interrupt may take a
> while to complete, so each interrupt must be done in its own thread

Are you sure, calling interrupt is usually just about setting a flag no?

Having 1 thread for each interruption, could lead to hundred of
threads running for high throughput threads (500 res/s for example), it
won't scale.
Why can't we have 1 Thread (TimeoutChecker) called every N milliseconds
that checks all registered JMeterThreads to check and call interrupt if
necessary ?


> It should be possible to use a single shared instance of the
> ScheduledExecutorService; that could be lazily created using IODH. [I
> can try that with the current implementation]

See my note above


>
> As to whether the Timeout class should be a Timer or some other type
> of test element - that does not matter so long as it can be applied to
> the samplers individually or when in scope.
>
> I chose Timer because it was already called in the right place, but I
> assume JMeterThread can call any Test class provided that it
> implemented the SampleInterface.
>
> It must be one of the existing Test Element classes that are handled
> by the Menu system otherwise it will need special handling.
>
> The scope requirement rules out Config elements and Logic Controllers.

It does not seem like a pre-processor to me, nor a post-procesor, nor a
> Listener
>
> So AFAICT the only remaining options are the Timer and Assertions.
>
> I think both are justifiable.

Why isn't it part of Sampler abstract class and as such a field in Sampler?



For me none of Timer nor Assertions are conceptually valid.
The behaviour is not a pause(so not Timer for me), it's not an Assertion
neither as for me an Assertion only checks something.
Although not fully satisfying it look to me more of a PreProcessor as it
sets a timeout on the Sampler , it can also be considered as a Post
Processor.



>
> The name of the class can of course be changed from InterruptTimer - I
> think that is probably not the best choice. Maybe something like
> SamplerTimeout?
>
Yes or SamplerTimeouter or SamplerInterrupter


-- 
Cordialement.
Philippe Mouawad.

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