You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by "Kevin A. Burton" <bu...@newsmonster.org> on 2005/01/03 08:25:10 UTC
Re: stacktrace information logger patch...
Ceki Gülcü wrote:
>
> Hi Kevin,
>
> My comments below are entirely based on the use case where you have a
> log statement indicating some method, say X, was called. However, you
> do not know how, why or who called X. That is where your %stacktrace
> word comes into play.
>
> Your current contribution is a good step forward but not entirely
> sufficient to address the above use case. If you use the long form,
> since all logging output will contain a stacktrace, your log output
> will be long and verbose making it hard to decipher. If you use
> the short form, the log output will be easier to read. However, a
> single
> line of stack trace may not be enough to clearly understand the chain
> of events resulting in the invocation of X. You need more slack with
> more lines of stack.
Well I agree.. I think I even noted this in the source if you read all
the comments ;)
Here's what I said inline:
> //NOTE: when option is an integer here we could just return
> this many
> //lines. As an example you could have %stacktrace{5} and only
> return 5
> //lines of the stack.
I didn't consider this to be a big feature for my development style so I
didn't implement this right away.
Note that if you're correct here then this same thing applies to
%throwable which doesn't implement this behavior.
>
> So, instead of full/short, make the argument to %stacktrace an integer
> specifying the lines of stack to print. With no arguments, the full
> stack trace should be printed.
Yes...
>
> The second more elaborate enhancement comes in the form of filter
> chains. Define a filter chain which returns a positive value only for
> logs containing the output from X. When you pass that filter chain to
> %stacktrace. it should be able to output a stack trace *only* for X,
> ignoring the other logging events. This will result in a much cleaner
> log output allowing you to quickly focus on the actual problem.
>
> Here is a configuration file to make my clarify the point.
>
Wow... that seems like a big CPU hit.
I actually just thought it would be good to log an individual class. So
you just define your categoriy as org.peerfear.ClassToDebug and then use
that with your %stacktrace ... which would be a lot faster.
>
> There is only one missing architectural piece from our end. Although
> Logger, Appender and Layout objects hold a reference to the
> LoggerRepository where they are embedded, PatternConverters do not. If
> you are interested, I can quickly fix this shortcoming.
If you want to attempt all this work then you should backport the same
functionality for %throwable. IMO I just think we need this basic
support ASAP and then if necessary we can add it in later.
Remember the current log4j doesn't have this feature at ALL .. so these
can just be RFEs for later.
Kevin
--
Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an
invite! Also see irc.freenode.net #rojo if you want to chat.
Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
If you're interested in RSS, Weblogs, Social Networking, etc... then you
should work for Rojo! If you recommend someone and we hire them you'll
get a free iPod!
Kevin A. Burton, Location - San Francisco, CA
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: stacktrace information logger patch...
Posted by Ceki Gülcü <ce...@qos.ch>.
The contents of my last message were not completely accurate. Since
StringMatchFilter invokes the String.indexOf() method, chaining one or
more StringMatchFilter instances will have a measurable impact on
performance. However, it should be trivial to devise a filter similar
to StringMatchFilter but based on String.equals(). Such a filter would
have zero or near zero impact on performance for the case being
discussed. More below.
At 07:22 AM 1/6/2005, Kevin A. Burton wrote:
>Ceki Gülcü wrote:
>
>>I'd expect the CPU hit to be minimal because the filter chain will
>>only be applied on enabled log statements. For the vast majority of
>>events the filter will not match. In the case of two unequal string,
>>string comparison returns very quickly. I'd go as far as speculating
>>that the CPU hit would be beyond the measurable.
>
>Whats the status of this patch? Was it accepted?
Yes, it was accepted but expect it to be enhanced as suggested
earlier.
>I'm not prepared to do all this extra work because honestly I don't need
>it for my app.
Are you saying that losing the context of the surrounding log messages
is not a concern in your particular use-case? My intuition tells me
that having the stack trace for a specific call plus all the
surrounding log messages would be very useful.
>Kevin
>
>--
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: stacktrace information logger patch...
Posted by "Kevin A. Burton" <bu...@newsmonster.org>.
Ceki Gülcü wrote:
> At 08:25 AM 1/3/2005, Kevin A. Burton wrote:
>
>> Ceki Gülcü wrote:
>>
>>>
>>> The second more elaborate enhancement comes in the form of filter
>>> chains. Define a filter chain which returns a positive value only for
>>> logs containing the output from X. When you pass that filter chain to
>>> %stacktrace. it should be able to output a stack trace *only* for X,
>>> ignoring the other logging events. This will result in a much cleaner
>>> log output allowing you to quickly focus on the actual problem.
>>>
>>> Here is a configuration file to make my clarify the point.
>>
>> Wow... that seems like a big CPU hit.
>
>
> I'd expect the CPU hit to be minimal because the filter chain will
> only be applied on enabled log statements. For the vast majority of
> events the filter will not match. In the case of two unequal string,
> string comparison returns very quickly. I'd go as far as speculating
> that the CPU hit would be beyond the measurable.
Whats the status of this patch? Was it accepted?
I'm not prepared to do all this extra work because honestly I don't need
it for my app. Maybe in the future though..
Kevin
--
Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an
invite! Also see irc.freenode.net #rojo if you want to chat.
Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
If you're interested in RSS, Weblogs, Social Networking, etc... then you
should work for Rojo! If you recommend someone and we hire them you'll
get a free iPod!
Kevin A. Burton, Location - San Francisco, CA
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: stacktrace information logger patch...
Posted by Ceki Gülcü <ce...@qos.ch>.
At 08:25 AM 1/3/2005, Kevin A. Burton wrote:
>Ceki Gülcü wrote:
>>
>>The second more elaborate enhancement comes in the form of filter
>>chains. Define a filter chain which returns a positive value only for
>>logs containing the output from X. When you pass that filter chain to
>>%stacktrace. it should be able to output a stack trace *only* for X,
>>ignoring the other logging events. This will result in a much cleaner
>>log output allowing you to quickly focus on the actual problem.
>>
>>Here is a configuration file to make my clarify the point.
>Wow... that seems like a big CPU hit.
I'd expect the CPU hit to be minimal because the filter chain will
only be applied on enabled log statements. For the vast majority of
events the filter will not match. In the case of two unequal string,
string comparison returns very quickly. I'd go as far as speculating
that the CPU hit would be beyond the measurable.
>I actually just thought it would be good to log an individual class. So
>you just define your categoriy as org.peerfear.ClassToDebug and then use
>that with your %stacktrace ... which would be a lot faster.
If you direct the logs of an individual class, then you will be
loosing the information provided by the larger context, i.e. the
information provided by the surrounding logs. If that context is not
important, then obviously your approach is much simpler.
>Kevin
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org