geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@gluecode.com>
Subject Logging vs. Tracing
Date Tue, 09 Nov 2004 19:54:08 GMT
This came up at ApacheCon last year and during the startup phase of HOWL 
but given we are thinking about cracking open logging I thought it was 
worth bringing it up again.

The problem with logging is that it tells you what broke but not how you 
got there. TRACE level logging provides low-level diags but has too much 
overhead for you to want to have it on in production.

Enter: HOWL Trace

What this does is provide a way of capturing trace level detail into a 
thread-local ring buffer with very little overhead (i.e. rules say you 
should not do any object creation or string operations). Most of the 
time this data just gets thrown away but should some interesting event 
happen then the data from the ring-buffer gets formatted and logged 
along with the event.

Hopefully the ring-buffer contains enough history that you can work out 
how you got to the point of failure.

Think of the classic NPE - you know from the stacktrace which variable 
is null but to fix the bug you need to find out why the method that was 
supposed to initialize it was never called.

This is a different model from util.logging, log4j or clogging but 
similar to those used on mainframes (initial concept came from the Bull 
guys). It is not the same as buffered logging in log4j as it relies on 
being able to save the inital trace entries with very little overhead so 
the buffer sits in front of the logging framework whereas in log4j 
buffered logging keeps the normal API but just optimizes away output 
operations.

Anyway, just refloating the idea if anyone is interested.
--
Jeremy

Mime
View raw message