jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: BackendListener client design needs more work
Date Mon, 09 Feb 2015 00:15:17 GMT
On 8 February 2015 at 18:16, Philippe Mouawad
<> wrote:
> On Sunday, February 8, 2015, sebb <> 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.

Yes, which is also not all that user  friendly.

> The limit comes from it genericity
> What do you find not easy to use ?

There layout is just a list of names ane values; there's no logical
grouping and no s
>> 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.

I meant listener, but in fact that won't quite work.
No matter, the main issue is that the Gui is not as easy to use as it could be.

>> 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#createSampleR
esult 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.

I doubt it.

> 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.

Perhaps, though that is not very efficient.

>> 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 ?

I don't know how long this will take.

I thought you were keen to get a release out soon.

View raw message