On 22 August 2012 21:43, Philippe Mouawad <philippe.moua...@gmail.com> wrote: > On Wed, Aug 22, 2012 at 7:21 PM, sebb <seb...@gmail.com> wrote: > >> On 22 August 2012 17:52, Milamber <milam...@apache.org> wrote: >> > 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 >> >> >> >> I don't see the point of replacing the existing logging. >> What benefit would we get? >> > Does current implementation support MDC or NDC ?
No idea what they are. > Other features I see: > > - Parameterized log messages : > http://slf4j.org/faq.html#logging_performance We already use the if enabled wrappers. > - Marker objects : see > - > > http://stackoverflow.com/questions/10766411/overriding-the-logging-methods-logger-warn-in-slf4j, > > - http://logback.qos.ch/manual/layouts.html#Evaluators Do we really need this functionality? Looks rather complicated to me. > > What's wrong with the existing functionality? >> > it is based on a retired project (Excalibur). It kind of hurts me. Irrelevant if it works. > 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 In what way is it limited? AFAIK, it's similar to commons-logging. > 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. That's quite difficult to do. >> >> 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 > So? AFAICT, most of that relates to using and implementing logging, rather than configuring logging levels, which is the main issue for end users. > > 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 ? See separate thread. >> >> >> >> >> >> 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. >> >> >> > > > > -- > Cordialement. > Philippe Mouawad.
