Hi Ceki,
I thought I would explain the current design on Chainsaw and how it
uses the threads and buffers. This will also help with people understanding
Chainsaw and making improvements. :-)
At the moment Chainsaw supports collecting events from multiple servers
using the SocketAppender. The LoggingReceiver class creates a thread for
accepting connections from SocketAppenders. For each connection received,
an instance of LoggingReceiver.Slurper is created with a separate thread.
The purpose of this class is to receive the sent LoggingEvent objects as
quickly as possible. Remember that Checkstyle supports pausing the updating
of the display. However, it should continue to collect events so as to
not cause grief for the sending SocketAppenders.
The events received by LoggingReceiver.Slurper are added to the model,
which is an instance of MyTableModel. Note, because Chainsaw is receiving
events from multiple clients, it must order the events based on time. It
cannot assume that events will be received in chronological order from
clients due to network latency issues. The ordering is done by the use of
the class MyTableModel.Comparator. I feel that for Chainsaw to use
CyclicBuffer, then it must support also support ordering (which may cause
problems?).
To support the ability to pause the updating of the display and to filter
events, the MyTableModel class has the following three buffers:
- mPendingEvents - holds the incoming events whilst updating is paused;
- mAllEvents - events are transferred from mPendingEvents into this buffer
when not paused. This is done periodically (currently every
second) by a thread. The reason for the delay
was to minimise number screen updated, but your email
indicates this may not be necessary.
- mFilteredEvents - holds the events after apply the filter criteria. These
are the events that are displayed in the UI. The model
attempts to efficiently keep this buffer up to date.
The rest of the code in Chainsaw is to display the events in a Swing table,
and allow the updating of the filter criteria. Oh, and to also display
events logged to a file in XML format.
My plan is to add version 1.1 of Chainsaw to Log4J, plus a couple of patches
I have received as well. After that, I suggest that Chainsaw is updated
based on the input from this mailing list. Mark Womack and I have already
had discussions and he has some good ideas. I particularly like the idea of
allowing different receivers being plugged in.
Please find my other comments embedded below.
Regards,
Oliver
PS: I look forward to contributing to Log4J.
> -----Original Message-----
> From: Ceki Gulcu [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 22 March 2002 03:10
> To: [EMAIL PROTECTED]
> Subject: An alternative JTable
>
>
> 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.
I like it! I agree that Chainsaw should not have unbounded buffers and
use something like CyclicBuffer. However, I feel that Chainsaw need to
continue to support ordering of events based on time, so it is not able
to use CyclicBuffer as is.
The use of a single renderer is interesting. This maybe a way to change
Chainsaw to be more flexible in what fields are displayed....
>
> 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.
It is not clear to me how this scheme could support the ability to pause
updating the display. If people feel this feature is not required, then
I am happy to remove it and only have two buffers.
>
> 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.
I agree, that is why I wrote Checkstyle. :-)
Seriously, I propose adding Checkstyle initially for just checking Chainsaw.
This is as an aid for people (read me initially) to conform to your coding
style. If it proves successful, then it can be extended to cover the rest
of the Log4J source code.
>
> 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.
I'd suggest using it on Log4J first to prove it's usefulness on a real
Jakarta project first.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
