On Tue, Nov 26, 2013 at 1:05 AM, sebb <[email protected]> wrote: > On 23 November 2013 13:48, Philippe Mouawad <[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.
> > 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 > >>> >> since it's an in-memory repo (although this can be done in SQL > >>> databases), > >>> >> see http://redis.io/topics/benchmarks > >>> >> > >>> >> > >>> >>> I'm not yet convinced that this is how we should be extending > JMeter. > >>> >>> > >>> >> > >>> >> I don't understand this argument, it would be another string for > >>> JMeter, > >>> >> my implementation is only 2 classes + properties for I18N ? > >>> >> > >>> >> What do you propose in this case ? > >>> >> > >>> >> > >>> >> > >>> >>> > Thanks > >>> >>> > Regards > >>> >>> > Philippe > >>> >>> > > >>> >>> > On Monday, October 28, 2013, Philippe Mouawad wrote: > >>> >>> > > >>> >>> >> > >>> >>> >> > >>> >>> >> On Monday, October 28, 2013, sebb wrote: > >>> >>> >> > >>> >>> >>> On 28 October 2013 01:26, sebb <[email protected]> wrote: > >>> >>> >>> > On 26 October 2013 20:23, Philippe Mouawad < > >>> >>> [email protected]> > >>> >>> >>> wrote: > >>> >>> >>> >> Hello, > >>> >>> >>> >> These days Cloud based testing is becoming popular and > having > >>> to > >>> >>> >>> distribute > >>> >>> >>> >> test data accross many servers through CSV can become > painful > >>> if > >>> >>> not > >>> >>> >>> >> impossible. > >>> >>> >>> >> > >>> >>> >>> >> Even without Cloud, when using distributed testing you > always > >>> have > >>> >>> to > >>> >>> >>> >> replicate your data on all servers, which is a painful > manual > >>> step. > >>> >>> >>> >> > >>> >>> >>> >> Shouldn't we introduce a new DataSet more suitable for these > >>> use > >>> >>> cases > >>> >>> >>> ? > >>> >>> >>> >> > >>> >>> >>> >> We could do it in many different ways: > >>> >>> >>> >> - Integrate an automatic CSV replicator, this would remain > >>> simple > >>> >>> and > >>> >>> >>> would > >>> >>> >>> >> not introduce any tier, but with cloud based it would not > >>> >>> horizontally > >>> >>> >>> >> scale easily > >>> >>> >>> > > >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >>> > Not sure I follow the scaling argument. The file would only > >>> have to > >>> >>> be > >>> >>> >>> > copied once before the test proper starts. > >>> >>> >>> > From then on, the data is accessed locally. > >>> >>> >>> > > >>> >>> >> > >>> >>> >> > >>> >>> >> The scale word was not good, In my thinking the issue is more > about > >>> >>> >> deploying/copying/splitting the file among nodes or cloud > members. > >>> A > >>> >>> >> centralized access makes it far easier. > >>> >>> >> > >>> >>> >> > >>> >>> >>> > However, with a database, each node will need at least one > >>> >>> connection > >>> >>> >>> > to the database, and every time more data is needed there > will > >>> be > >>> >>> >>> > network traffic. > >>> >>> >>> > Or the database has to be running on the server node. > >>> >>> >>> > > >>> >>> >> > >>> >>> >> > >>> >>> >> Agree, I was not saying anything different. But as I said this > can > >>> be > >>> >>> >> useful for middle or low volume > >>> >>> >> > >>> >>> >> > >>> >>> >>> >> - Use a JDBC DataSet, but we would need to ensure it > performs > >>> >>> fine, and > >>> >>> >>> >> jdbc protocol is not well suited for cloud based deployment > >>> (But it > >>> >>> >>> could > >>> >>> >>> >> also be an interesting feature for Continuous Integration) > >>> >>> >>> >> - Use a NOSQL repository (Redis seems to me the best > choice) > >>> , see > >>> >>> >>> this > >>> >>> >>> >> high level summary which I find interesting > >>> >>> >>> >> > >>> >>> >>> > >>> >>> > >>> > http://www.journaldunet.com/developpeur/outils/comparatif-des-bases-nosql/comparatif-des-bases-nosql-tableau-de-synthese.shtml > >>> >>> >>> >> > >>> >>> >>> >> I have implemented a new Redis (based on Java library for > >>> Redis) > >>> >>> >>> DataSet > >>> >>> >>> >> which I plan to commit if no objection. > >>> >>> >>> >> > >>> >>> >>> >> It will introduce 2 new dependencies with Apache License: > >>> >>> >>> >> - Jedis (http://code.google.com/p/jedis/) > >>> >>> >>> >> - commons-pool > >>> >>> >>> > > >>> >>> >>> > There is also a dependency on Redis, but I guess that would > not > >>> be > >>> >>> >>> bundled. > >>> >>> >>> > >>> >>> >>> > >>> >>> >> no need to anything else than jedis + commons-pool > >>> >>> >> > >>> >>> >> > >>> >>> >>> I've just noticed that Redis is provided as source which needs > to > >>> be > >>> >>> >>> built before use. > >>> >>> >>> If it's difficult to copy CSV files to cloud nodes, it seems > to me > >>> >>> >>> it's going to be much harder to install Redis. > >>> >>> >>> In which case additional network traffic will be needed to > access > >>> the > >>> >>> >>> database. > >>> >>> >>> > >>> >>> >>> Also there is no official Windows release. > >>> >>> >>> > >>> >>> >>> >> Thoughts ? > >>> >>> >>> > > >>> >>> >>> > Is MongoDB not suitable? > >>> >>> >>> > We already include a jar for it. > >>> >>> >>> > > >>> >>> >> > >>> >>> >> > >>> >>> >> Mongodb is more document oriented and has another type of use > >>> cases. > >>> >>> One > >>> >>> >> interesting feature of redis is lists where you can pop a line > it > >>> will > >>> >>> not > >>> >>> >> be available to next calls, it is suitable for tests that need > >>> >>> uniqueness > >>> >>> >> accross all nodes. > >>> >>> >> > >>> >>> >>> >> -- > >>> >>> >>> >> Regards. > >>> >>> >>> >> Philippe M. > >>> >>> >>> >> @philmdot <https://twitter.com/philmdot> > >>> >>> >>> > >>> >>> >> > >>> >>> >> > >>> >>> >> -- > >>> >>> >> Cordialement. > >>> >>> >> Philippe Mouawad. > >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> > > >>> >>> > -- > >>> >>> > Cordialement. > >>> >>> > Philippe Mouawad. > >>> >>> > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> Cordialement. > >>> >> Philippe Mouawad. > >>> >> > >>> >> > >>> >> > >>> > > >>> > > >>> > -- > >>> > Cordialement. > >>> > Philippe Mouawad. > >>> > >> > >> > >> > >> -- > >> Cordialement. > >> Philippe Mouawad. > >> > >> > >> > > > > > > -- > > Cordialement. > > Philippe Mouawad. > -- Cordialement. Philippe Mouawad.
