logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject An alternative JTable
Date Thu, 21 Mar 2002 16:09:53 GMT
Hi Oliver,

I have just added a small program called TableAppender in
contribs/CekiGulcu/TableAppender.java to our CVS repository. This
program illustrates a possible algorithm to manage a large number of
logging events. This particular implementation uses a fixed sized
buffer although a dynamically growing buffer would work just as well.
My tests show that TableAppender can handle the insertion of 100'000
events in about 4 seconds. These 4 seconds include the painting of those
100'000 elements in the table. Let me know what you think of it.

On a related but different register, chainsaw as it exists today has
3 buffers. A buffer for pending events that chainsaw just
received from the client but has not yet processed, a second buffer
containing all the elements received so far, and a third buffer that
contains the events that remain after filtering by the various
filters.

I would suggest an alternative architecture where only two buffers are
needed. One for collecting events and another buffer to contain the
events after filtering. The latter buffer would also serve as the
underlying data structure for the TableModel. I also believe that
there is no need to have a separate thread to process the events such
as the MyTableModel.Processor. Let me know if you wish to pursue this
further.

As for introducing Checkstyle (http://checkstyle.sourceforge.net/) in
log4j, I am favorable to the idea although I do not yet see a burning
need for it. Being the only active committer I do not have much
trouble sticking to the log4j coding style which happens to be my
favorite. A while back, there was a long and somewhat unpleasant
discussion on general@jakarta mailing list on coding conventions. It
did not go anywhere. As a result of this discussion however, I along
numerous other people concluded that the only way to enforce coding
standards is using an automated process.

Gump (http://jakarta.apache.org/gump/) is a concrete example of the
power of such an automated process.  It detects backward incompatible
changes in project A that breaks project B which depends on A. It has
been an extremely useful tool to preserve log4j's backward
compatibility.

I think Checkstyle can prove to be an indispensable tool. As long as it
doesn't bring development to a screeching halt, you are welcome to add
style checks to log4j. You might also want to suggest it to others on
the general@jakarta list.

--
Ceki



--
To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>


Mime
View raw message