Troubleshooting
Problem
Log Rollover unreliability Issue in log4j at high volumes and multiple threads
Symptom
We tried using the RollingFileAppender and the DailyRollingFileAppender in
Log4j to rollover the log files in Production. However, we found that under
heavy volume (maybe when multiple threads are logging) the log4j rollover
mechanism breaks down. It does crazy things, like not logging to the new file.
It continues to write to the renamed file. Some of the threads may even stop
logging.
PART: Platform-Config 5.0 Platform
PRODUCT: Distributed
Order Management
Cause
Resolving The Problem
Resolution is to use this script to do the rolover, and to disable log4j's
rolling appenders.
cp curr_log_file.log old_log_file_0718.log
cat
/dev/null > curr_log_file.log
the 0718, of course is generated by the
script before.
There can be multiple users (unix users) accessing the
log files for logging as well as running the rollover script. When running the
rollover script, the user which runs the rollover script does not have write
permissions on the log file, so cat /dev/null > logfile_name fails.
So
solution is to this is to do a umask with the user which creates the log file..
by doing a 002, this gives write permissions to other users in the same group.
This solves the problem.
Another observation is that weblogic takes no
responsibility for rollover except for weblogic.log and access.log, which have
rollover built in (in weblogic console, you can specify rollover parameters).
Historical Number
PRI49060
Product Synonym
[<p><b>]Fact[</b><p>];
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21528617