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
