On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad < philippe.moua...@gmail.com> wrote:
> Restarting the discussion about logger. > > I agree with sebb java.util.logging is not great compared to slf4j/logback > , log4j or commons-logging. > > My opinion is slf4j/logback would be the best choice as it's: > > - the most up to date > - is the next evolution of LOG4J for logback > - was build from commons-logging experience for SLF4J > - logback seems to have more features than log4j > Perhaps, some issue with the logback dual licences (EPL and LGPL). I'm not sure if we can used the logback with only the choice of EPL licence... The commons-logging and the Log4j are under AL2.0, seems better to use an ASF product in an ASF product? ;-) > > > I think we should really remove dependency on Apache Excalibur. > > > Regards > > Philippe > // Copying dialog from another thread: > > Philippe says > >> As we are now in these big changes (static final, interface cleanup ... > ) > >> Sebb, milamber is it ok for you if I start migration to commons-logging > ? > >> > > > > > Milamber says: > > Why commons-loggings (not updated since 2008)? > > Sebb says: > AIUI it's not been updated since it works; there has been no need to update > it. > > > Log4J ? > > > or directly java.util.logging.*? > > That's broken, according to what I read. > > On Mon, Jan 23, 2012 at 1:39 PM, Philippe Mouawad < > philippe.moua...@gmail.com> wrote: > > > Hello Sebb, > > My responses below. > > Regards > > Philippe > > > > On Mon, Jan 23, 2012 at 1:02 PM, sebb <seb...@gmail.com> wrote: > > > >> On 23 January 2012 06:49, Philippe Mouawad <philippe.moua...@gmail.com> > >> wrote: > >> > Regarding logging, > >> > It CAN Go fast if we share work and each of us takes one SRC folder. > >> > It's à matter f search replace for 90%. > >> > >> It's still the same amount of work, no matter how many people do it. > >> [Possibly more, if you allow for co-ordination overheads] > >> > >> Generally it's the last 10% that takes all the effort. > >> > > => I agree , I volunteer to do it if you agree after release. > > > >> > >> Definitely not something to be started just before a release. > >> > >> => It was not my intention, it is just after the release. > > > > > >> Also, we would still need to keep the jars unless we rewrote > >> OldSaveService - or made it optional. > >> > >> > > >> > Regarding pool i am not sure to there is an datasourceelemnt That > has à > >> > Maxpool property and looking at code it seemed the excalibur > datasource > >> > was using this property. > >> > Commons jdbc BasicDatasource was looking very close to it. > >> > > >> > Regards > >> > Philippe > >> > On Monday, January 23, 2012, Anthony Johnson <ans...@gmail.com> > wrote: > >> >> On Sun, Jan 22, 2012 at 9:28 PM, sebb <seb...@gmail.com> wrote: > >> >>> On 23 January 2012 01:46, Anthony Johnson <ans...@gmail.com> wrote: > >> >>>> On Sun, Jan 22, 2012 at 8:29 PM, sebb <seb...@gmail.com> wrote: > >> >>>>> > >> >>>>> On 22 January 2012 13:04, Philippe Mouawad < > >> philippe.moua...@gmail.com> > >> > wrote: > >> >>>>> > Hello, > >> >>>>> > I noticed there was some plan to remove Excalibur logger > >> dependency. > >> >>>>> > What is the new selected component to replace it ? > >> >>>>> > > >> >>>>> > - log4j > >> >>>>> > - slf4J+logback > >> >>>>> > >> >>>>> Given that the main focus of JMeter is HTTP, and we use Apache > >> >>>>> HttpClient, if we do replace logging it will be sensible to use > the > >> >>>>> same, i.e. Commons Logging. > >> >>>>> > >> >>>>> But it is a huge job to do this; every single file that uses > logging > >> >>>>> will need to be updated. > >> >>>>> > >> >>>>> As well as changing all the documentation, config files etc. > >> >>>>> > >> >>>>> > > >> >>>>> > When do we plan this migration ? > >> >>>>> > >> >>>>> Not yet. > >> >>>>> > >> >>>>> > Working on 41788 > >> >>>>> > <https://issues.apache.org/bugzilla/show_bug.cgi?id=41788>I > >> noticed > >> >>>>> > javadocs for excalibur where no more available on internet. > >> >>>>> > > >> >>>>> > I suppose the same question will arise regarding DataBase > Sampler > >> > pool. > >> >>>>> > What are the candidates: > >> >>>>> > > >> >>>>> > - Tomcat JDBC Pool : > >> >>>>> > http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html > >> >>>>> > - Commons DBCP ? > >> >>>>> > >> >>>>> I wonder whether there's really any point supporting database > >> pooling > >> >>>>> at all, given that the focus of JMeter is on independent test > >> threads. > >> >>>>> > >> >>>> > >> >>>> JMeter definitely needs persistent database connections which is > >> >>>> easily accomplished with database pooling. JMeter loses usefulness > >> if > >> >>>> it has to open a connection at sample time since this is a lot more > >> >>>> expensive than running optimized SQL. > >> >>>> > >> >>>> Also, some database features rely on persistent connections to be > >> >>>> optimized such as PreparedStatement caches. > >> >>> > >> >>> JMeter uses persistent connections; the connection is established > by: > >> >>> > >> >>> > >> > > >> > http://jmeter.apache.org/usermanual/component_reference.html#JDBC_Connection_Configuration > >> >>> > >> >>> This is a different matter from sharing connections between threads. > >> >>> > >> >>> The per-thread (non-shared) pool is currently implemented as a pool > >> >>> size of 1 per thread. > >> >>> > >> >> > >> >> The preferred way(per the sarcastic "why use pooling" in the docs:-) > >> >> is not very nice code-wise. If I have a 1,000 thread test then I > will > >> >> have a 1,000 excaliber thread pool objects in memory and 1,000 > >> >> per-thread poolMap objects. Getting rid of pooling in JMeter would > >> >> definitely make this code better. > >> >> > >> >> On the other hand, their are nice features from the pooling such as > >> >> connection testing, keep-alives and such. Some of those would need > to > >> >> be implemented if you guys decided to rip out pooling. > >> >> > >> >> Regardless, you responded to my only concern and I learned > >> >> something(despite having written several JDBC Test Plans in the > >> >> past:-/) > >> >> > >> >>>>> Adding pooling effectively means that JMeter is testing the > pooling > >> as > >> >>>>> well as the database. > >> >>>>> > >> >>>>> > I made some Load tests for an ECommerce site comparing the 2 > pools > >> > and the > >> >>>>> > first one seems to be a little better performing (specially in > >> > exhaustion > >> >>>>> > cases) > >> >>>>> > > >> >>>>> > although Commons DBCP quality is great. > >> >>>>> > >> >>>>> I don't think database pooling is really necessary for JMeter, so > >> the > >> >>>>> performance is not a big issue; tests that want to exercise a > >> database > >> >>>>> should not be using pooling - or at least should not be using a > >> >>>>> pooling solution which is fixed by JMeter. > >> >>>>> > >> >>>>> I don't know whether it's possible to create a datasource which > >> >>>>> includes pooling, if so, then that is the way to go - i.e. support > >> >>>>> data sources (I don't think we do currently). > >> >>>>> > >> >>>>> > > >> >>>>> > -- > >> >>>>> > Cordialement. > >> >>>>> > Philippe Mouawad. > >> >> > >> > > >> > -- > >> > Cordialement. > >> > Philippe Mouawad. > >> > > > > > > > > -- > > Cordialement. > > Philippe Mouawad. > > > > > > > > > > > -- > Cordialement. > Philippe Mouawad. >
