Q. With respect to logging, how much of a good thing is too much of a good thing?
A. Logging is a powerful application tool that, in my opinion, has been under-utilized. Many architects may have implemented some sort of a strategy for logging common application events to a text file for debugging. In a few cases, full-featured audit strategies have been implemented for complete documentation of every customer transaction, perhaps for review at a later date. Most of the time, however, logging is being used just to report major warning or error conditions within the application code.

If you haven't looked at the cost of logging to your production application, you will probably be surprised by just how many CPU cycles are burned by it. Look for a long, steady burn rate in your CPU utilization - whatever the CPU utilization of your WLS process "settles" to between any visible spikes. If your WLS instance isn't handling any highly concurrent user loads, this "sizzle" or "baseline" can often be accounted for by the writes to your log file, particularly if you see much of the utilization at the system level of the OS.

One of the most common culprits is unhandled exceptions on core application paths. As any performance primer will explain, exception-handling routines are among the most expensive in any application's code. It gets even more expensive when your handling strategy is to print every single exception - whether meaningful or not - to standard out or standard error. In some cases, Wily has seen customers generating megabytes of logfile every hour - all with the same exception throws from the same use case in the application. I don't recommend doing that.

Once you get unnecessary exceptions out of the logging picture, you should still be thinking carefully about what information, if any, you want your application to be logging to a file. JMX is another great option for handling many of the problems that some architects have only considered logging to solve, but make sure you have thought through what you are going to do with the data you publish via JMX.

Q. Why should I deploy my application as an EAR file?
A. In most organizations that are currently using Java in production, there are at least a few legacy projects from the early years of Java's development as an enterprise platform. As the Java platform matured, feature and functionality were added to address many of the most common business problems encountered by the early pioneers. With today's full J2EE solution there are a myriad of facilities available that I recommend you take advantage of. To that end, many people have asked me why they should spend their time repackaging old applications.

When confronted with that question, some IT managers protest by saying that they really don't need the ability to run multiple versions of a single application in a single application server. They say that they're happy continuing to get away with the arrangement they have used to date, loading their application code on the system classpath.

There are, however, far more compelling reasons to go ahead and do the work. Perhaps the most important should be fear of the unknown. With even a minor revision to your application server new classes and new versions of classes can appear unexpectedly on your system classpath ahead of your application code. A new revision of an application that has been running perfectly fine, and has gone through all its QA smoke tests without issue, can die inexplicably in production as a result of an uncontrolled change to one of the key classes that it happens to share with the server. Unless you truly know everything that's going in and out of weblogic.jar with each point release of the BEA WebLogic Server, this should scare you. Bugs like these can be extremely difficult to discover.

If you have an environment where you're running more than one application per server instance, then the problem gets exponentially more complicated from there. Repackaging your application as a proper enterprise archive not only shelters you from many of these types of application problems, but allows you to take full advantage of a modern application server's ability to host dozens of different applications without conflict. Build-and-release management becomes less costly and more straightforward when each revision of an application is encapsulated by a single file - you can perform rollbacks more quickly and easily, should they be necessary, and you have the additional peace of mind that any tool that purports to support Java enterprise ought to read your application in this format. Additionally, any future work on your application should become easier as well.

As always, I invite you to send an e-mail to asklew@syscon.com if you have any performance-related questions about JVMs, Java applications, BEA WebLogic Server, or connections to back-end systems.