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: Graphite Listener
Date Wed, 01 Jan 2014 21:36:32 GMT
opened new discussion for backend listener implementation


On Wed, Jan 1, 2014 at 9:50 PM, sebb <sebbaz@gmail.com> wrote:

> On 1 January 2014 20:46, Philippe Mouawad <philippe.mouawad@gmail.com>
> wrote:
> > On Wed, Jan 1, 2014 at 9:43 PM, Philippe Mouawad <
> philippe.mouawad@gmail.com
> >> wrote:
> >
> >>
> >>
> >>
> >> On Wed, Jan 1, 2014 at 9:41 PM, sebb <sebbaz@gmail.com> wrote:
> >>
> >>> On 1 January 2014 20:28, Philippe Mouawad <philippe.mouawad@gmail.com>
> >>> wrote:
> >>> > On Wed, Jan 1, 2014 at 8:04 PM, sebb <sebbaz@gmail.com> wrote:
> >>> >
> >>> >> On 1 January 2014 15:08, Philippe Mouawad <
> philippe.mouawad@gmail.com>
> >>> >> wrote:
> >>>
> >>> <snip/>
> >>>
> >>> >> Seems to me all this could be done by having a generic interface
to
> >>> >> enable the raw results to be saved to whatever backend is required.
> >>> >>
> >>> >
> >>> > We could refactor code in the following way:
> >>> > - GraphiteListener => BackendListener
> >>> > - Introduce Backend Interface
> >>> > - Backend would be called in testStarted/testEnded and within the
> >>> existing
> >>> > run() to send metrics
> >>> > - There would be a select box to select backend. Backend
> implementations
> >>> > would be searched within classpaths
> >>> > - Graphite part and PickleMetricsManager would be moved to Graphite
> >>> Backend.
> >>> >
> >>> > We could after that add a JBDC Backend.
> >>>
> >>> That sounds a lot better.
> >>>
> >>> >>
> >>> >> What I don't agree with is yet more code that is very specific
to a
> >>> >> single 3rd party software solution.
> >>> >>
> >>> >> Whatever is added needs to be
> >>> >> - generally useful to the JMeter population. Niche requirements
> should
> >>> >> be met by 3rd party add-ons developed for the purpose.
> >>> >> - use a generic API, for example like JSR223, JDBC etc.
> >>> >>
> >>> >> I understand your wish but take the history of JMeter. At some
time
> >>> there
> >>> > was a need for custom scripting but no standard like BSF of JSR223.
> >>> > So you selected Beanshell . Once standard was introduced we moved to
> it.
> >>>
> >>> Actually, I think BSF was available, but I did not know about it.
> >>>
> >>
> > So you chose a popular third party at that time, and you did very well I
> > think if you look at JMeter history :-)
>
> Perhaps, but I think it would have worked just as well - if not better
> - if I had chosen to use BSF.
>
> > I think we should accept to make the best choice at the time the choice
> is
> > done, not the best theoretical choice :-)
>
> I think we need to learn from our mistakes.
>
> >
> >>> > I think we cannot wait for all standards to exist, for example if we
> >>> take
> >>> > NoSQL Databases, it is hard to tell when a JDBC equivalent will be
> >>> > available, does it means we should
> >>> > wait until they are available ? I don't think so.
> >>>
> >>> If there is no standard, then we need to look very carefully at what
> >>> JMeter needs as regards an API.
> >>> We should define an API to suit JMeter which can then be implemented
> >>> for specific NoSQL implementations.
> >>>
> >>> It does not have to be a fully fledged NoSQL API - in fact it should
> >>> probably not reference NoSQL at all, but should allow the repository
> >>> to be JDBC as well.
> >>>
> >>> Sorry my note was kind of out of subject, it was refering to last Redis
> >> discussion.
> >> Regarding the Backend discussion, of course if will be totally
> >> independent, could be file, jdbc, jms, no sql, graphite ...
> >>
> >>
> >>> >
> >>> >> >
> >>> >> >
> >>> >> >> Regards,
> >>> >> >> Vladimir Sitnikov
> >>> >> >>
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > --
> >>> >> > Cordialement.
> >>> >> > Philippe Mouawad.
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Cordialement.
> >>> > Philippe Mouawad.
> >>>
> >>
> >>
> >>
> >> --
> >> Cordialement.
> >> Philippe Mouawad.
> >>
> >>
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>



-- 
Cordialement.
Philippe Mouawad.

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