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: BackendListener client design needs more work
Date Sun, 08 Feb 2015 18:16:07 GMT
On Sunday, February 8, 2015, sebb <sebbaz@gmail.com> wrote:

> I've just had a look at the BackendListener implementation.
> [Sorry, I should have spent some time on this when it was first added.]
>
> Although it clearly works, it does not seem to me to be a particularly
> user-friendly design.
> The GUI is not very easy to use.
>
> it follows the same gui design as Java Sampler one.
The limit comes from it genericity
What do you find not easy to use ?



> Would it not be possible to implement the Gui and sampler classes as
> stand-alone classes?


Not clear for me, as I don't see sampler here.

>
> These can all derive from the same abstract parent class(es).
>
> ==
>
> Also, it looks like the underlying BackendListener is duplicated for
> each GUI Listener in the test plan. So each sample will be processed
> multiple times, and there will be multiple queues.


True but have a look at BackendListenerClient#createSampleResult which
would be impacted by the redesign.
Also not sure there will be more than 2 Listeners in a plan.
If we create a good live listener (Graphite) + and good Post Test listener
(Report generator) then it would be enough for most cases.


That seems very wasteful.
>
> At the moment there is only one possible listener type so there is no
> need to create more than one listener in a given scope, however in
> future there will presumably be more.
>
> I think it would be better if the backend listeners were able to
> register themselves with a single BackendListener which then
> distributes the sample as needed to the eventual recipients.
>
> I've not looked into how this would fit in with scoped listeners; it
> may be necessary to allow for muliple listeners, one in each scope,
> and then allow for different listener types to be attached to the
> different scopes. This needs further research.
>
> ==
>
> Unlike existing Listeners, there does not seem to be any way to limit
> processing to only successful/failed samples.
>
> Not sure this is needed .
Backend implementation can do the filtering itself through
createSamplerResult by returning null.

>
> I think the current implementation needs rethinking.
> If it is to be included in the next release as it currently stands, I
> think it needs to be very clearly documented as being subject to
> change.
>


Can't you rework it before release ?

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