You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2014/06/01 21:26:41 UTC
[jcs] logging
Hi
I have two main point to discuss regarding the logging:
1) LogHelper stuffI committed. Idea was to cache isDebugEnabled to get a if
(boolean) complexity and not go through the logging framework which can
imply several layers (filter, appender, handler, logger...) for nothing and
slow down caching (which has more perf constraints than other backends.
This really depends on the logger you use but we can't suppose it is the
one we benched against. Solutions I see: a) keep LogHelper, b) remove logs
(some are useless I think), 3) other?
2) logger api used. ATM we use [logging] but it will surely be an issue for
TomEE when integrated ([logging] is the less integrated framework -
compared to JUL or SLF4J where we don't have the choice at all) and I think
we'd be happy to remove it from the container to let it be application
oriented if we can. Any idea to make it hurtless? This doesn't urge and
doesn't block anything but if someone has an awesome idea it would be
welcomed ;)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
Re: [jcs] logging
Posted by Benedikt Ritter <be...@gmail.com>.
Send from my mobile device
> Am 02.06.2014 um 21:51 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> @Thomas: never said [logging] is bad and JUL is better. Sorry if I was not
> clear. All logging facades don't handle very well EE case for several good
> or bad reasons. [logging] is as good as slf4j for it (even better out of
> the box IIRC). JUL is far to be perfect but is in the JVM (so no
> dependency). The second point was just an open one. We'll want to get
> JCS/JCache in TomEE in few months and logging is not the best solution we
> have ATM. A little facade/factory would be great but once again this is not
> a blocker now. Mentionned it to let you have it in mind when it will come
> back.
>
>
> About 1 you are right and wrong. Right that I keep in mind in memory case
> (concurrenthashmap to caricature it a bit) because it is a very common
> case. Right that JCS is not only it and its biggest value is not here.
> However I can't agree when you say you don't care about this case. JCS is a
> cache and if caching is as slow as the cached computation then it is not as
> useful as it could be. Back to the logging I benched it months ago for
> OpenEJB and it really depends the configuration of the logger and the impl.
> Most of the time it is fine but if you want business debug logs only and
> you have several appenders by logger then you get an noticeable overhead
> (it was shouting in Tomcat classloader which is called very often at boot
> and had a lot of isLogEnabled(FINE) some month ago).
>
> That said I don't want to fight too long on it so if you really think it is
> wrong you can revert this part and I'll come back with a sample when I'll
> find time to work with it on a real project (until now I only used
> test/sample projects).
I trust Romains assement of this topic.
Benedikt
>
>
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
> 2014-06-02 20:51 GMT+02:00 Thomas Vandahl <tv...@apache.org>:
>
>>> On 01.06.14 21:26, Romain Manni-Bucau wrote:
>>> Hi
>>>
>>> I have two main point to discuss regarding the logging:
>>> 1) LogHelper stuffI committed. Idea was to cache isDebugEnabled to get a
>> if
>>> (boolean) complexity and not go through the logging framework which can
>>> imply several layers (filter, appender, handler, logger...) for nothing
>> and
>>> slow down caching (which has more perf constraints than other backends.
>>> This really depends on the logger you use but we can't suppose it is the
>>> one we benched against. Solutions I see: a) keep LogHelper, b) remove
>> logs
>>> (some are useless I think), 3) other?
>>
>> Remember what I said about use cases. You have your one-and-only use
>> case in your mind. Others may have other use cases, accept dependencies,
>> need debugging. A quick scan of the net shows several places where the
>> performance issue has been discussed. Examples:
>>
>> http://learnertobeginner.blogspot.de/2010/06/how-to-use-isdebugenabled-effectly.html
>> or http://logging.apache.org/log4j/2.x/performance.html
>>
>> Both suggest that the isDebugEnabled() call can be neglected for most of
>> the cases. It is not ConcurrentHashMap you are competing with.
>>
>> Create a benchmark, run it and see for yourself. Logging is the least of
>> our performance issues, I promise.
>>
>>> 2) logger api used. ATM we use [logging] but it will surely be an issue
>> for
>>> TomEE when integrated ([logging] is the less integrated framework -
>>> compared to JUL or SLF4J where we don't have the choice at all) and I
>> think
>>> we'd be happy to remove it from the container to let it be application
>>> oriented if we can. Any idea to make it hurtless? This doesn't urge and
>>> doesn't block anything but if someone has an awesome idea it would be
>>> welcomed ;)
>>
>> I'm not sure I understand what you want to tell me. Do you consider it
>> good manners to jump into a community and tell them right away how
>> shitty their logging framework is? My experiences with JUL are no better
>> by the way.
>>
>> That said, I don't really care about the logging framework. Move to JUL
>> if you believe it's faster. But please avoid shooting yourself in the
>> foot by prematurely optimizing things and removing important features.
>>
>> Bye, Thomas.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jcs] logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Thomas: never said [logging] is bad and JUL is better. Sorry if I was not
clear. All logging facades don't handle very well EE case for several good
or bad reasons. [logging] is as good as slf4j for it (even better out of
the box IIRC). JUL is far to be perfect but is in the JVM (so no
dependency). The second point was just an open one. We'll want to get
JCS/JCache in TomEE in few months and logging is not the best solution we
have ATM. A little facade/factory would be great but once again this is not
a blocker now. Mentionned it to let you have it in mind when it will come
back.
About 1 you are right and wrong. Right that I keep in mind in memory case
(concurrenthashmap to caricature it a bit) because it is a very common
case. Right that JCS is not only it and its biggest value is not here.
However I can't agree when you say you don't care about this case. JCS is a
cache and if caching is as slow as the cached computation then it is not as
useful as it could be. Back to the logging I benched it months ago for
OpenEJB and it really depends the configuration of the logger and the impl.
Most of the time it is fine but if you want business debug logs only and
you have several appenders by logger then you get an noticeable overhead
(it was shouting in Tomcat classloader which is called very often at boot
and had a lot of isLogEnabled(FINE) some month ago).
That said I don't want to fight too long on it so if you really think it is
wrong you can revert this part and I'll come back with a sample when I'll
find time to work with it on a real project (until now I only used
test/sample projects).
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-06-02 20:51 GMT+02:00 Thomas Vandahl <tv...@apache.org>:
> On 01.06.14 21:26, Romain Manni-Bucau wrote:
> > Hi
> >
> > I have two main point to discuss regarding the logging:
> > 1) LogHelper stuffI committed. Idea was to cache isDebugEnabled to get a
> if
> > (boolean) complexity and not go through the logging framework which can
> > imply several layers (filter, appender, handler, logger...) for nothing
> and
> > slow down caching (which has more perf constraints than other backends.
> > This really depends on the logger you use but we can't suppose it is the
> > one we benched against. Solutions I see: a) keep LogHelper, b) remove
> logs
> > (some are useless I think), 3) other?
>
> Remember what I said about use cases. You have your one-and-only use
> case in your mind. Others may have other use cases, accept dependencies,
> need debugging. A quick scan of the net shows several places where the
> performance issue has been discussed. Examples:
>
> http://learnertobeginner.blogspot.de/2010/06/how-to-use-isdebugenabled-effectly.html
> or http://logging.apache.org/log4j/2.x/performance.html
>
> Both suggest that the isDebugEnabled() call can be neglected for most of
> the cases. It is not ConcurrentHashMap you are competing with.
>
> Create a benchmark, run it and see for yourself. Logging is the least of
> our performance issues, I promise.
>
> > 2) logger api used. ATM we use [logging] but it will surely be an issue
> for
> > TomEE when integrated ([logging] is the less integrated framework -
> > compared to JUL or SLF4J where we don't have the choice at all) and I
> think
> > we'd be happy to remove it from the container to let it be application
> > oriented if we can. Any idea to make it hurtless? This doesn't urge and
> > doesn't block anything but if someone has an awesome idea it would be
> > welcomed ;)
>
> I'm not sure I understand what you want to tell me. Do you consider it
> good manners to jump into a community and tell them right away how
> shitty their logging framework is? My experiences with JUL are no better
> by the way.
>
> That said, I don't really care about the logging framework. Move to JUL
> if you believe it's faster. But please avoid shooting yourself in the
> foot by prematurely optimizing things and removing important features.
>
> Bye, Thomas.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [jcs] logging
Posted by Thomas Vandahl <tv...@apache.org>.
On 01.06.14 21:26, Romain Manni-Bucau wrote:
> Hi
>
> I have two main point to discuss regarding the logging:
> 1) LogHelper stuffI committed. Idea was to cache isDebugEnabled to get a if
> (boolean) complexity and not go through the logging framework which can
> imply several layers (filter, appender, handler, logger...) for nothing and
> slow down caching (which has more perf constraints than other backends.
> This really depends on the logger you use but we can't suppose it is the
> one we benched against. Solutions I see: a) keep LogHelper, b) remove logs
> (some are useless I think), 3) other?
Remember what I said about use cases. You have your one-and-only use
case in your mind. Others may have other use cases, accept dependencies,
need debugging. A quick scan of the net shows several places where the
performance issue has been discussed. Examples:
http://learnertobeginner.blogspot.de/2010/06/how-to-use-isdebugenabled-effectly.html
or http://logging.apache.org/log4j/2.x/performance.html
Both suggest that the isDebugEnabled() call can be neglected for most of
the cases. It is not ConcurrentHashMap you are competing with.
Create a benchmark, run it and see for yourself. Logging is the least of
our performance issues, I promise.
> 2) logger api used. ATM we use [logging] but it will surely be an issue for
> TomEE when integrated ([logging] is the less integrated framework -
> compared to JUL or SLF4J where we don't have the choice at all) and I think
> we'd be happy to remove it from the container to let it be application
> oriented if we can. Any idea to make it hurtless? This doesn't urge and
> doesn't block anything but if someone has an awesome idea it would be
> welcomed ;)
I'm not sure I understand what you want to tell me. Do you consider it
good manners to jump into a community and tell them right away how
shitty their logging framework is? My experiences with JUL are no better
by the way.
That said, I don't really care about the logging framework. Move to JUL
if you believe it's faster. But please avoid shooting yourself in the
foot by prematurely optimizing things and removing important features.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jcs] logging
Posted by Thomas Vandahl <tv...@apache.org>.
On 02.06.14 17:02, Romain Manni-Bucau wrote:
> actually these logs are really debug log not intended to be activated in
> prod excepted if there is a big issue (@thomas: if you can confirm it would
> be great).
Yes, logging is for debugging purposes mostly. But if you remove them:
how would you do just this - debug? In a non-trivial environment
(distributed caches, disk caches etc) it can be essential to see what
happens beneath.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jcs] logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
actually these logs are really debug log not intended to be activated in
prod excepted if there is a big issue (@thomas: if you can confirm it would
be great).
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-06-02 16:20 GMT+02:00 Phil Steitz <ph...@gmail.com>:
> On 6/1/14, 12:26 PM, Romain Manni-Bucau wrote:
> > Hi
> >
> > I have two main point to discuss regarding the logging:
> > 1) LogHelper stuffI committed. Idea was to cache isDebugEnabled to get a
> if
> > (boolean) complexity and not go through the logging framework which can
> > imply several layers (filter, appender, handler, logger...) for nothing
> and
> > slow down caching (which has more perf constraints than other backends.
> > This really depends on the logger you use but we can't suppose it is the
> > one we benched against. Solutions I see: a) keep LogHelper, b) remove
> logs
> > (some are useless I think), 3) other?
>
> Let me ask the obvious, probably naive question: does this component
> really need logging at all? Could you expose what clients need via
> JMX or other means? It would be good to know what clients are
> actually using / depending on.
>
> Phil
> >
> > 2) logger api used. ATM we use [logging] but it will surely be an issue
> for
> > TomEE when integrated ([logging] is the less integrated framework -
> > compared to JUL or SLF4J where we don't have the choice at all) and I
> think
> > we'd be happy to remove it from the container to let it be application
> > oriented if we can. Any idea to make it hurtless? This doesn't urge and
> > doesn't block anything but if someone has an awesome idea it would be
> > welcomed ;)
> >
> >
> > Romain Manni-Bucau
> > Twitter: @rmannibucau
> > Blog: http://rmannibucau.wordpress.com/
> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > Github: https://github.com/rmannibucau
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [jcs] logging
Posted by Phil Steitz <ph...@gmail.com>.
On 6/1/14, 12:26 PM, Romain Manni-Bucau wrote:
> Hi
>
> I have two main point to discuss regarding the logging:
> 1) LogHelper stuffI committed. Idea was to cache isDebugEnabled to get a if
> (boolean) complexity and not go through the logging framework which can
> imply several layers (filter, appender, handler, logger...) for nothing and
> slow down caching (which has more perf constraints than other backends.
> This really depends on the logger you use but we can't suppose it is the
> one we benched against. Solutions I see: a) keep LogHelper, b) remove logs
> (some are useless I think), 3) other?
Let me ask the obvious, probably naive question: does this component
really need logging at all? Could you expose what clients need via
JMX or other means? It would be good to know what clients are
actually using / depending on.
Phil
>
> 2) logger api used. ATM we use [logging] but it will surely be an issue for
> TomEE when integrated ([logging] is the less integrated framework -
> compared to JUL or SLF4J where we don't have the choice at all) and I think
> we'd be happy to remove it from the container to let it be application
> oriented if we can. Any idea to make it hurtless? This doesn't urge and
> doesn't block anything but if someone has an awesome idea it would be
> welcomed ;)
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jcs] logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Well because [logging] was longly broken in a not flat classloading
environment (didnt check last release but almost all logging facade got
this issue at a point) and because almost nothing in TomEE stacks uses it,
it is not as integrated as log4j, slf4j or JUL (which is the default). Main
issue I saw was leaks (due to classloaders management) and potentially
wrong config detection (same reason). I hacked in TomEE slf4j to force it
to be smart cause users often rely on it but not [logging yet]. Until here
you can say that's a TomEE issue (as fair as saying that's a JCS one).
Then you can't seriously use JUL with [logging] cause of this method (from
Jdk14Logger):
protected void log( Level level, String msg, Throwable ex ) {
Logger logger = getLogger();
if (logger.isLoggable(level)) {
// Hack (?) to get the stack trace.
Throwable dummyException = new Throwable();
StackTraceElement locations[] = dummyException.getStackTrace();
// LOGGING-132: use the provided logger name instead of
the class name
String cname = name;
String method = "unknown";
// Caller will be the third element
if( locations != null && locations.length > 2 ) {
StackTraceElement caller = locations[2];
method = caller.getMethodName();
}
if( ex == null ) {
logger.logp( level, cname, method, msg );
} else {
logger.logp( level, cname, method, msg, ex );
}
}
}
getStackTrace will be too expensive that you will just want
logger.isLoggable(level) to be false. There is no magic to make it
consistent and fast. Half of impl doesn't respect method to avoid it.
But then the question is regarding JCache. All apache spec impl uses JUL as
primary logger (allowing then to override it) to avoid to force the
container/environment and let the user deciding what to use. Here the issue
is JCache is built on top of JCS. So either both use JUL or if JCS uses
[logging] by default then JCache will bring [logging] and force its usage.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-06-02 8:17 GMT+02:00 Jörg Schaible <jo...@swisspost.com>:
> Romain Manni-Bucau wrote:
>
> > Hi
> >
> > I have two main point to discuss regarding the logging:
> > 1) LogHelper stuffI committed. Idea was to cache isDebugEnabled to get a
> > if (boolean) complexity and not go through the logging framework which
> can
> > imply several layers (filter, appender, handler, logger...) for nothing
> > and slow down caching (which has more perf constraints than other
> > backends. This really depends on the logger you use but we can't suppose
> > it is the one we benched against. Solutions I see: a) keep LogHelper, b)
> > remove logs (some are useless I think), 3) other?
> >
> > 2) logger api used. ATM we use [logging] but it will surely be an issue
> > for TomEE when integrated ([logging] is the less integrated framework -
> > compared to JUL or SLF4J where we don't have the choice at all)
>
> ?? Can you explain a bit more? You can logging redirect to use JUL, so what
> kind of issues are you thinking about?
>
> > and I
> > think we'd be happy to remove it from the container to let it be
> > application oriented if we can. Any idea to make it hurtless? This
> doesn't
> > urge and doesn't block anything but if someone has an awesome idea it
> > would be welcomed ;)
> >
> >
> > Romain Manni-Bucau
> > Twitter: @rmannibucau
> > Blog: http://rmannibucau.wordpress.com/
> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > Github: https://github.com/rmannibucau
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [jcs] logging
Posted by Jörg Schaible <jo...@swisspost.com>.
Romain Manni-Bucau wrote:
> Hi
>
> I have two main point to discuss regarding the logging:
> 1) LogHelper stuffI committed. Idea was to cache isDebugEnabled to get a
> if (boolean) complexity and not go through the logging framework which can
> imply several layers (filter, appender, handler, logger...) for nothing
> and slow down caching (which has more perf constraints than other
> backends. This really depends on the logger you use but we can't suppose
> it is the one we benched against. Solutions I see: a) keep LogHelper, b)
> remove logs (some are useless I think), 3) other?
>
> 2) logger api used. ATM we use [logging] but it will surely be an issue
> for TomEE when integrated ([logging] is the less integrated framework -
> compared to JUL or SLF4J where we don't have the choice at all)
?? Can you explain a bit more? You can logging redirect to use JUL, so what
kind of issues are you thinking about?
> and I
> think we'd be happy to remove it from the container to let it be
> application oriented if we can. Any idea to make it hurtless? This doesn't
> urge and doesn't block anything but if someone has an awesome idea it
> would be welcomed ;)
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jcs] logging
Posted by sebb <se...@gmail.com>.
On 1 June 2014 20:26, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Hi
>
> I have two main point to discuss regarding the logging:
> 1) LogHelper stuffI committed. Idea was to cache isDebugEnabled to get a if
> (boolean) complexity and not go through the logging framework which can
> imply several layers (filter, appender, handler, logger...) for nothing and
> slow down caching (which has more perf constraints than other backends.
> This really depends on the logger you use but we can't suppose it is the
> one we benched against. Solutions I see: a) keep LogHelper, b) remove logs
> (some are useless I think), 3) other?
3) Use a more efficient logger.
and/or
4) For methods that have multiple debug logs, cache the isDebugEnabled
setting locally.
> 2) logger api used. ATM we use [logging] but it will surely be an issue for
> TomEE when integrated ([logging] is the less integrated framework -
> compared to JUL or SLF4J where we don't have the choice at all) and I think
> we'd be happy to remove it from the container to let it be application
> oriented if we can. Any idea to make it hurtless? This doesn't urge and
> doesn't block anything but if someone has an awesome idea it would be
> welcomed ;)
That really belongs in a separate thread.
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org