|
Problem(Abstract) |
Various issues have arisen since IBM® WebSphere®
Application Server V5.0, and higher, or when the concept of rolling log
files was introduced. |
|
|
|
Cause |
Starting in WebSphere Application Server version 5.0 and
5.1, WebSphere logging and tracing introduced the concept of rolling log
files. The intention of rolling log files was to prevent a single log file
from growing so large that it would consume all of the free space on a
file system, or become too large to view in a typical text editor. This
new feature can be configured to "rollover" a log file when it reaches a
certain size or at a specified hour. The underlying implementation of this
rollover feature is to rename the existing log file (for example:
SystemOut.log) to something based on the current date and time
(for example: SystemOut_06.10.31_23.00.00.log), then create a new
file with the same filename as the original (SystemOut.log) and
begin writing to that file. |
|
|
Resolving the
problem |
Various issues can arise when the rename fails. The most
common reason for a file rename to fail is that another thread or process
has opened an output stream to the same file. The behavior of the rename
and the other output stream vary depending on the operating system. For
example, on Microsoft® Windows® operating systems, the file rename will
fail if another output stream is opened to the same file. In this case,
WebSphere Application Server would clear the log file and begin writing
log entries from scratch, deleting the log records from the existing file.
This problem is resolved by PK32428,
which will continue writing to the same log even if the rename fails -
note that this means that the log file could continue to grow unbounded.
On Solaris, the rename will succeed, but the other output stream will now
continue to write to the newly-renamed file, leaving the user with the
impression that the other output stream has stopped writing.
In order to avoid these anomalies, the best practice is to configure
WebSphere Application Server logs so that they only write to one unique
file. For example, a user could configure two servers to write to the same
SystemOut.log file. When one server started to rollover the log
file, it would either fail to rename the file and delete the previous
contents of the log file (unless PK32428 is applied), or it would rename
the file and write to the new SystemOut.log file, but the other
server would continue to write to the newly-renamed file. This same
behavior could occur if one server tried to "consolidate" log files by
using the same physical log file for multiple logs (for example: Using
SystemOut.log to log standard out and standard err). This erratic
behavior can only be avoided by ensuring that no two threads or processes
write to the same file. Also note that some text editors can have the same
effect as an output stream. Therefore, it is recommended that users view
"active" log files by using read-only tools like Notepad, tail, and so
on. |
|
|
|
|
Cross Reference information |
Segment |
Product |
Component |
Platform |
Version |
Edition |
Application Servers |
Runtimes for Java Technology |
Java SDK |
|
|
|
|
|
|