opened new discussion for backend listener implementation
On Wed, Jan 1, 2014 at 9:50 PM, sebb <[email protected]> wrote: > On 1 January 2014 20:46, Philippe Mouawad <[email protected]> > wrote: > > On Wed, Jan 1, 2014 at 9:43 PM, Philippe Mouawad < > [email protected] > >> wrote: > > > >> > >> > >> > >> On Wed, Jan 1, 2014 at 9:41 PM, sebb <[email protected]> wrote: > >> > >>> On 1 January 2014 20:28, Philippe Mouawad <[email protected]> > >>> wrote: > >>> > On Wed, Jan 1, 2014 at 8:04 PM, sebb <[email protected]> wrote: > >>> > > >>> >> On 1 January 2014 15:08, Philippe Mouawad < > [email protected]> > >>> >> 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.
