********** 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.
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
