axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kellogg, Richard" <RKell...@MICROS.COM>
Subject RE: isDebugEnabled calls
Date Tue, 12 Aug 2003 21:03:34 GMT
+1 That sounds great.


-----Original Message-----
Sent: Tuesday, August 12, 2003 5:02 PM
Subject: RE: isDebugEnabled calls

Yep, that's the idea.  The difference is that the dynamically altered
changes will only show up on new messages after the point where the change
appears.  So every instance of DeserializationContextImpl (for example)
would have an instance variable with the value of isDebugEnabled.  It would
use that value for its entire lifecycle, which == one request/response loop.


-----Original Message-----
From: Steve Loughran []
Sent: Tuesday, August 12, 2003 1:53 PM
Subject: Re: isDebugEnabled calls wrote:
> My profiling shows that an appreciable amount of time is spent on
> isDebugEnabled calls.  It's not huge, but they add up to 5 seconds of time
> over 100 calls because they are invoked almost 400,000 times in over those
> 100 calls.
> I'm wondering whether we couldn't adopt the policy that says debug logging
> is either enabled or disabled at creation time for certain heavily used
> objects, like DeserializationContextImpl.  So, you'd either get debug
> logging or you wouldn't, on a message by message basis.  Changes won't
> effect until the next message.  DeserializationContextImpl accounts for
> almost all of the calls described above.
> I am, of course, volunteering to do the work.  What say you?
> Eric

I say that assuming people are just using static log4j config, then this 
is a definite performance boost.

My only concern is for live tuning of production servers, those in which 
you suddenly want to turn on diagnostics for a bit without a restart. If 
the changes you make can still get picked up between messages, i.e. on a 
live system without a restart, then I am for it.


View raw message