********** Logging in J2EE/EJB world ******** ***** Overview The needs and scenarios in a distributed computing environment are very different from desktop computing. Server programs must be available 24 x 7 and you can not assume your server is monitored by human all the time. So, server programs need logging: log errors and log events. The development environment is different as well. When you develop a desktop program you use a debugger to set break points. When something is wrong, you can simply restart your program. Unfortunately, this is not the case for server programs. In the first phase of development, you can run both server and client on your desktop machine and fix all bugs you can find. In the real world the situation is much more complex when many clients concurrently access your server. Things get even more complicated when your server load balances and failovers. It is impossible to set break points when the server is in production. The only thing you can do is tracing log message. ***** Features we need for logging Logging facilities should be dynamically configurable. Un-wanted log messages should be easily filtered out: they are too noisy and there is always a performance penalty associated with logging. Logging messages should be persistent. When they are persistent, they are the resource for tracing. So a source code level tracing is a natural companion of logging. Logging must be centralized. In a distributed environment (clustering) the your server can dynamically move EJBs and other components from one physical machine to another due to load balancing and failover. If logging messages stay on local machine, log messages will be all over those machines and it would be very difficult to analysis these messages. Logging must be chronological. When your server is concurrently accessed by many clients, there are time dependency issues. Logging must be easy to use. If it is too complicated, it will be error prone. Logging part of the program will not be tested as thoroughly as the main part. When something happens and you want see log messages, it is the worst time to find out that you have a bug in logging or you did not configured logging system correctly. Alert facilities must be companions of logging. If some thing happens, you need administrator's attention. There only one practical persistent solution: use database to store logging messages. There are some implementation and operation issues too. For example, your log database should not be a part of your transaction. If some thing happens, the log message should not be ROLLBACKed. Just like log message printed on your screen, you can not take them back. So the connection between log system and log database must be a dedicated one. In a clustering environment, there are many physical machines and many servers. Your logging attributes (configuration information) must be stored in a central place, for example, the log database. Logging system must fetch logging attributes from the log database. There is a performance penalty to pay. But the penalty may not be severe for you application. On the other hand, if your system is stable, you should be able to download log attributes from the log database to the local machine and use attributes from local machine instead. This will give you a performance boost. Log method call should provide caller's class name, method name, time stamp and other information. If you hard code this information, your program would be very difficult to maintain. So you need a tool to rectify these information before you deploy your EJBs or other components. ***** Rejected options EJB specification prohibits file IO. So logging on files are not acceptable, although many server leave a back door for you. There are some other issues as well. Asynchronized JMS as the mechanism is not the best choice. It can not guarantee log messages be chronological. Suppose you have machine A which logs message "first". Later machine B logs message "second". JMS guarantees delivery, but does not guarantee timing. You may see the message "second" before "first". You can get around of this problem by fetching a unique id from a central place each time a log method is called. But the extra remote access would be expensive. Another work-a-round is use time stamp as log id in a synchronized time network system. But the resolution of time stamp may not be good enough (usually at millisecond level) and may not be unique if you have many physical machines. You will get more performance overhead by using JMS than direct database access. On the surface, you call JMS based log method and it returns immediately, so your main program goes faster. But the part of JMS on your local machine will compete computing resources (both memory and CPU) with your main program. ***** SuperLogging is designed to resolve above issues SuperLogging of Super is designed to resolve above issues. You can get it from http://www.acelet.com. It is free for users of open source server. It is free for development. The features: * SuperLogging is platform neutral and vendor neutral. * An open source wrapper is provided, if you want switch to other logging software, you do not need to modify your source code. You only need to modify this wrapper which is just a router, only a few lines. * Log threshold: filter out low level logging requests. * Class registration: filter out not-registered classes. * Log mode: Verbose, Quiet and Conditional. * Scope: Global Dynamic: get log attributes from the central place each time. Global Static: download log attributes to local machine. Singleton: working within one JVM: does not need the central place. * Trace: source code level trace: when you click on a line of message, the source code shows up and the line in question will be marked. * It is a fail-stop facility. If the log database is down, an alert message will be sent and logging will be quiet and your EJBs can still run as usual. * Redress: a tool to rectify some log information. ********** Comments welcome ********** ---- To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "unsubscribe jonas-users". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
