On Wed, Aug 22, 2012 at 7:21 PM, sebb <[email protected]> wrote: > On 22 August 2012 17:52, Milamber <[email protected]> wrote: > > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad < > > [email protected]> 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 > >> > > I don't see the point of replacing the existing logging. > What benefit would we get? > Does current implementation support MDC or NDC ? Other features I see:
- Parameterized log messages : http://slf4j.org/faq.html#logging_performance - Marker objects : see - http://stackoverflow.com/questions/10766411/overriding-the-logging-methods-logger-warn-in-slf4j, - http://logback.qos.ch/manual/layouts.html#Evaluators What's wrong with the existing functionality? > it is based on a retired project (Excalibur). It kind of hurts me. Not much documentation on web, I had to search last time when implementing 41788 and 53261. API is limited compared to Commons-logging, log4j , slf4j I remember when starting using jmeter (I knew at that time log4j, commons-logging) I had to modify log level somewhere, I search a while because it was a new mechanism to learn (had jmeter relied on existing conf of log4j or other I would have found this very rapidly, ActiveMQ for example uses commons-logging, slf4j and possibly logback). > Would we lose any functionality by changing? > I don't think so. But maybe you should detail all the features and we could check. > > It took a lot of work to get everything set up properly; and will be a > very major undertaking to change everything. > It's not just changes to class import statements and creating a > different logger. > There's documentation, and the way we use properties to control > logging different classes and packages. > If that changes, it could break some user installations. > I agree it changes but log4j, commons-logging, slf4j are such standard that it's very easy to find info, for example look at stackoverflow statistics: - http://stackoverflow.com/questions/tagged/slf4j : 390 questions - http://stackoverflow.com/questions/tagged/log4j : 2170 questions - http://stackoverflow.com/questions/tagged/logback : 320 questions - http://stackoverflow.com/questions/tagged/apache-commons-logging : 61 questions - logkit, avalon, excalibur : 0 questions Users will also need to get learn a different way of controlling logging. > > We could rely on underlying product documentation which is quite well known (log4j , logback ) instead of creating our own mechanism . We could then remove all Logging Configuration paragraph from jmeter.properties. > > > > > 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. > > We still use parts of Excalibur for JDBC pooling. > > I don't see the point of pooling if you are testing JDBC; it then > becomes as much a test of the pool rather than JDBC. > Don't understand this > > If we do want to support pooling, it should be selectable. > However I don't know if there is a standard Pooling API, so that might > not be possible. > > Why not use commons-dbcp or tomcat-pool for this ? > >> > >> > >> 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 < > >> [email protected]> wrote: > >> > >> > Hello Sebb, > >> > My responses below. > >> > Regards > >> > Philippe > >> > > >> > On Mon, Jan 23, 2012 at 1:02 PM, sebb <[email protected]> wrote: > >> > > >> >> On 23 January 2012 06:49, Philippe Mouawad < > [email protected]> > >> >> 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 <[email protected]> > >> wrote: > >> >> >> On Sun, Jan 22, 2012 at 9:28 PM, sebb <[email protected]> wrote: > >> >> >>> On 23 January 2012 01:46, Anthony Johnson <[email protected]> > wrote: > >> >> >>>> On Sun, Jan 22, 2012 at 8:29 PM, sebb <[email protected]> wrote: > >> >> >>>>> > >> >> >>>>> On 22 January 2012 13:04, Philippe Mouawad < > >> >> [email protected]> > >> >> > 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. > >> > -- Cordialement. Philippe Mouawad.
