geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@coredevelopers.net>
Subject Re: [Logs] Re: Logging code and Garbage Collection
Date Fri, 15 Aug 2003 15:59:45 GMT
On Friday, August 15, 2003, at 07:54 AM, Berin Loritsch wrote:

> Dain Sundstrom wrote:
>> 1) cache the value and invalidate based on a notification from the 
>> logging framework
>> 2) cache the value and invalidate on an interval bases
>> Agreed?
>
>
> :/  Hmm.  What about using lastModified() semantics.  If the value has 
> not
> been modified in X number of minutes, then we can recheck the old 
> implementation
> of the isXEnabled.  The solution does not eat up a thread to do the 
> check.

I thought about that, but I thought that making a System call to get 
the current time is a fairly expensive operation to do on every call.  
I would have listed it as an option, but I consider it an 
implementation of option 2.

>> BTW here is my justification.  isDebugEnabled looks like this:
>> public boolean isDebugEnabled() {
>>     if (repository.isDisabled(Level.DEBUG_INT)) {
>>         return false;
>>     }
>>     return Level.DEBUG.isGreaterOrEqual(this.getEffectiveLevel());
>> }
>
>
> That's only one implementation.  It might be better to fix Log4J.  BTW,
> how does JDK 1.4 Logging work?

I agree it would be better to get this into Log4j, and I have heard 
that they are working on this.  As I said before when they do fix it, 
we can remove my class.

> <snip type="code">
>
>> According to the extensive testing Jeremy and I did on the fastest 
>> way to implement the locking system, the most expensive thing in raw 
>> java is volatile variables.  It was actually faster to synchronize 
>> and get the value, but that may reduce concurrency.  This was not a 
>> problem for locking as it is designed to control concurrency.  My 
>> code on the other hand, caches the value of this expensive call and 
>> keeps it in an non-synchronized non-volatile variable.  At noted in 
>> the code this is OK because boolean assignment is atomic and at the 
>> worst case we will have running threads with an outdated processor 
>> cache of the value, which is OK as this is designed to be an out of 
>> date cache.  So unless you turn off debug for the entire hierarchy 
>> there is no way my code can be slower and if you have turned it off 
>> for the entire hierarchy, my code should be no slower.
>
> Category is for an old version of Log4J, does this problem still exist 
> in
> the new code?

Check the code... Logger extends Category where all of the 
functionality exists, so yes the problem still exists.

> Anyway, I'm not trying to ruffle feathers, but just point out that the
> same thing can be done without eating up precious resources like 
> Threads.

Sure, this is one of the possible tradeoffs to alleviate (not fix) the 
problem, and with all things in engineering there are many other 
tradeoffs we could take.

-dain


Mime
View raw message