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 20:46:51 GMT
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 :-)

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

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