Hello, For information, as we didn't get consensus on commiting the piece of code to JMeter core and I didn't want to throw away the time I spent implementing it I have contributed it to third party jmeter-plugins project, it should be in next version of the plugins.
https://github.com/undera/jmeter-plugins/pull/22 I still think it would have been nice as is in core, creating a common gui/api for cloud based libs being a bit complex as config properties really differ as long as purposes. Regards Philippe M. On Thursday, December 19, 2013, Philippe Mouawad wrote: > > > > On Sat, Nov 30, 2013 at 10:52 AM, sebb <[email protected]<javascript:_e({}, > 'cvml', '[email protected]');> > > wrote: > >> On 27 November 2013 21:21, Philippe Mouawad >> <[email protected]<javascript:_e({}, 'cvml', >> '[email protected]');>> >> wrote: >> > On Tue, Nov 26, 2013 at 1:05 AM, sebb <[email protected]<javascript:_e({}, >> > 'cvml', '[email protected]');>> >> wrote: >> > >> >> On 23 November 2013 13:48, Philippe Mouawad < >> [email protected] <javascript:_e({}, 'cvml', >> '[email protected]');>> >> >> wrote: >> >> > Hello sebb, >> >> > What's your decision on this point ? >> >> >> >> I don't make the decisions - they are ideally arrived at by consensus; >> >> failing that, majority. >> >> >> >> > Still having objection to code commit ? >> >> >> >> Yes, because it seems wrong to include code for a specific database >> >> implementation. >> >> We should be implementing generic solutions. >> >> >> >> So would you be ok to go for Spring-data based implementation ? >> > It will impact number of embedded libraries. >> >> There are other possibilities for NoSQL as well, for example >> http://appscale.cs.ucsb.edu/datastores.html - AppScale >> > Commercial no ? > >> http://thrift.apache.org/ - Apache Thrift >> > > Didn't dig into it yet, but could you point me to a way to do it if you > already did ? > >> >> See also >> >> http://www.oracle.com/technetwork/database/nosqldb/overview/nosql-api-497225.html >> >> http://stackoverflow.com/questions/9252034/is-there-an-emerging-standard-api-for-nosql-databases >> >> http://stackoverflow.com/questions/3439878/are-there-any-nosql-standards-emerging >> >> Given that there is no standard like JDBC available (and there may >> never be), what I think needs to happen is to decide where in JMeter >> such databases may be useful (probably not only CSV Dataset) and then >> define a suitable API for this. >> Users can then implement the API in terms of whatever database they >> wish to use (which might include a JDBC implementation). >> This is not something to be rushed into. >> > > I don't totally agree with you, I prefer sometimes that we move forward > with "non perfect" thing and improve it in next steps. > > Also I am a bit annoyed that time I spent on this development is kind of > thrown away while it is really easy to use and have tested it rather > thoroughly. > > >> >> In any case, whatever is decided on belongs in a later version of JMeter. >> We first need to get out the version with various fixes to keytool etc. >> > > Dev is ready and could have been commited but would have agreed to wait. > > > > > >> > Thanks > >> > Regards > >> > Philippe > >> > > >> > > >> > On Fri, Nov 15, 2013 at 10:37 PM, Philippe Mouawad < > >> > [email protected]> wrote: > >> > > >> >> We could sue Spring-Data but it would introduce a lot of > dependencies. > >> >> > >> >> > >> >> On Fri, Nov 15, 2013 at 12:54 AM, sebb <[email protected]> wrote: > >> >> > >> >>> On 13 November 2013 21:59, Philippe Mouawad < > >> [email protected]> > >> >>> wrote: > >> >>> > Hello sebb, > >> >>> > Shall I commit this development or do we wait for 2.10.1 to be > >> released > >> >>> ? > >> >>> > >> >>> I am still concerned that this addition is specific to the Redis > >> server. > >> >>> I would much prefer to see a generic solution that can use various > >> >>> different kinds of servers. > >> >>> > >> >>> > When do you plan to commit your devs on keytool ? > >> >>> > >> >> > >> >> If I have time I will do it , I plan the following, if you want more > let > >> >> me know: > >> >> - Add keytool path property > >> >> - Add popup to be clear about error > >> >> - Add info about how to fix it > >> >> > >> >>> > >> >>> Sorry, have not been able to spend any time on this recently. > >> >>> > >> >>> > Thank you > >> >>> > Regards > >> >>> > Philippe > >> >>> > > >> >>> > > >> >>> > On Sat, Nov 2, 2013 at 3:05 PM, Philippe Mouawad < > >> >>> [email protected] > >> >>> >> wrote: > >> >>> > > >> >>> >> Hello Sebb, > >> >>> >> My answers below. > >> >>> >> > >> >>> >> On Sat, Nov 2, 2013 at 10:35 AM, sebb <[email protected]> wrote: > >> >>> >> > >> >>> >>> On 2 November 2013 08:28, Philippe Mouawad < > >> >>> [email protected]> > >> >>> >>> wrote: > >> >>> >>> > Hello, > >> >>> >>> > Can I proceed with commit these up coming days ? > >> >>> >>> > >> >>> >>> I'm not sure that the discussion was completed. > >> >>> >>> > >> >>> >>> As far as I can tell, the proposal only suits some types of > >> >>> >>> cloud-based test, and relies on 3rd party servers to hold the > data. > >> >>> >>> > >> >>> >> > >> >>> >> No in my opinion if fits many scenarios: > >> >>> >> - Cloud based tests, this one seems to me an important one, as > Cloud > >> >>> based > >> >>> >> usage are increasing > >> >>> >> - Distributed tests, even if it is possible to do it with CSV, > >> having > >> >>> the > >> >>> >> data in a remote server is much easier to manage than having to > >> >>> >> split/distribute on servers. Even it is true it requires some > >> skills to > >> >>> >> manage correctly the Redis server > >> >>> >> - Continuous integration tests where also having the data in a > >> >>> centralised > >> >>> >> , remote servers is easier than managing CSVs. In this case Redis > >> >>> server > >> >>> >> plays the same role as a JDBC repository > >> >>> >> - Compared to a database it should perform better for high load > >> tests > >> >>> >> si > > > > > -- > Cordialement. > Philippe Mouawad. > > > -- Cordialement. Philippe Mouawad.
