jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Apache Excalibur Logger
Date Wed, 22 Aug 2012 17:21:55 GMT
On 22 August 2012 17:52, Milamber <milamber@apache.org> wrote:
> On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad <
> philippe.mouawad@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?
What's wrong with the existing functionality?

Would we lose any functionality by changing?

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.

Users will also need to get learn a different way of controlling logging.

>
>
> 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.

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.

>>
>>
>> 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.mouawad@gmail.com> wrote:
>>
>> > Hello Sebb,
>> > My responses below.
>> > Regards
>> > Philippe
>> >
>> > On Mon, Jan 23, 2012 at 1:02 PM, sebb <sebbaz@gmail.com> wrote:
>> >
>> >> On 23 January 2012 06:49, Philippe Mouawad <philippe.mouawad@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 <ansoni@gmail.com>
>> wrote:
>> >> >> On Sun, Jan 22, 2012 at 9:28 PM, sebb <sebbaz@gmail.com>
wrote:
>> >> >>> On 23 January 2012 01:46, Anthony Johnson <ansoni@gmail.com>
wrote:
>> >> >>>> On Sun, Jan 22, 2012 at 8:29 PM, sebb <sebbaz@gmail.com>
wrote:
>> >> >>>>>
>> >> >>>>> On 22 January 2012 13:04, Philippe Mouawad <
>> >> philippe.mouawad@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.
>>

Mime
View raw message