Browse DevX
Sign up for e-mail newsletters from DevX


Build a Distributed Logging Framework Using Java RMI : Page 2

The new J2SE logging API brings Java developers a variety of ways to perform logging. One thing you can do is to build a logging framework for your distributed and multithreaded Java applications with Java RMI.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Log Locally vs. Remotely
Whether to log locally or remotely is a question that has no pat answer. The decision varies with each project. You need to consider a number of factors, such as network environment, hardware configuration, and software set up. For example, if you were developing an application for an embedded system with very limited system resources, it would make sense to have log requests come out of a network connection and be handled by a host with more capability. The rule of thumb is to use the method that will have the least impact on the overall system performance. This is vitally important in a time-critical system; the last thing you want is for logging to become a bottleneck.

You may also want to design your application to avoid having a single point of failure. I have seen systems designed to have one centralized log server, where all the satellite hosts dump log requests to it. In this configuration, when network traffic becomes overloaded, the log server becomes a single point of failure for the entire system. The logging framework in this article uses an in-memory buffer local to each network host as well as a runtime utility to access and control logs remotely, thus neutralizing these performance and reliability issues.

The In-Memory Log Handler
The in-memory log handler implements the Handler interface defined in the J2SE logging API and uses a ring buffer to hold log records. Whenever the buffer is full, the oldest log record is discarded. Listing 1 shows the code for MemLogHandler. The log handler invokes the publish() function only if a new log needs to be recorded. Because log filtering is done by the Logger object, the log handler doesn't need to decide if a request should be logged or not. The inherited close() and flush() functions are mainly used by a log handler that uses buffered streams. It needs an opportunity to flush the remaining log records in the stream before the handler itself is torn down, say, by garbage collection when the application is terminated. The getRecords() and removeAllRecords() functions are called when log records in the buffer need to be reported or deleted.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date