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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
