Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jmeter.apache.org
Received-SPF: pass (athena.apache.org: domain of philippe.mouawad@gmail.com
 designates 209.85.213.171 as permitted sender)
MIME-Version: 1.0
Date: Thu, 20 Nov 2014 21:15:41 +0100
Message-ID: 
 <CAH9fUpYMe_0vBMkXspQJZUVkK5QOMmRVQCvS_yMowPi0U1p8cw@mail.gmail.com>
Subject: Backend Listener / 55932
From: Philippe Mouawad <philippe.mouawad@gmail.com>
To: "dev@jmeter.apache.org" <dev@jmeter.apache.org>
Content-Type: multipart/alternative; boundary=001a11c3b40c0fe2b805084ffe30

--001a11c3b40c0fe2b805084ffe30
Content-Type: text/plain; charset=ISO-8859-1

Hi,
Just to inform you that I will be committing these days (probably on
saturday) the ALPHA implementation of this feature.

I will be adding as dependencies:

   - commons-math for Percentile computation. It has less memory impact
   than StatCalculator AFAIU and I only need a sliding Percentile.
   - commons-pool for SocketOutputStreamPoolFactory used by Graphite
   implementation

As a first Implementation of Backend there will be
GraphiteBackendListenerClient.

This will allow writing data in:

   - Graphite
   - InfluxDB which has Graphite listener
   - CollectD

Other implementation could also write to JDBC , JSON webservices, JMS,
Files ...

For now I am not satisfied with the Asynch Listener implementation as it
relies on ArrayBlockingQueue and my benchmark results show that for high
throughput tests, wait occurs on JMeterThreads.

I think commiting this feature will help the team understand what I am
talking about and improve it by having discussions on dev-list.

I think a better implementation would be to use something like LMax
Dispatcher as currently used by Log4j2 but had no time to implement it.

Another option might be to use Spring Reactor+Chronicle Queue (the in
memory one).

Regards
Philippe M.
@philmdot

--001a11c3b40c0fe2b805084ffe30--