Question

Historical Context: This problem ended up being not at all what I thought it was. The cause and solution are below, but the original posting is left for reference.

I’m developing a simple framework for periodically polling a directory for .properties files, then performing SQL queries and sending e-mails based on their configurations. Because each .properties file has the same spectrum of operations, they are all interpreted by the same Task class. But since they each represent different logical operations, they each get separate log files.

This is accomplished by sharing one instance of a log4j RollingFileAppender, and dynamically changing its output file based on a value in the .properties file. Since this is a single-threaded application, this works fine.

However, I’ve noticed that in certain situations, this RollingFileAppender will become closed, and the application will continue on obliviously except that now no logging takes place. I’ve only managed to catch this in action once, thanks to the console output, since usually this service is running as a background process on a Linux server. Here’s what happened:

1) StartScheduler, the main class, creates a new instance of TaskPoller every minute.

2) TaskPoller scans the directory, loads a little information from each .properties file, and determines if it should be run. It also has its own separate RollingFileAppender, which it retrieves via Logger.getLogger(TaskPoller.class). If a Task should be run, then it instantiates a Task object, passing in the specific .properties file to be run.

3) Task gets its RollingFileAppender, then calls fileAppender.setFile(“newtaskname.log”) and fileAppender.activateOptions() to change the output file location. Then, during its execution, something like this happens:

[TaskPoller]
...
task = new Task(fileName); //Points RollingFileAppender to the right place
if (!task.Execute())
    logger.warn(fileName + " returned with an error code."); //Succeeds
[Task.Execute]
...
try {
    dbDAO.Connect();
} catch (Exception e) {
    logger.fatal{"Database connection error.", e}; //Different RFA; Fails
    return false;
}
[DBDAO.Connect throws SQLException, ClassNotFoundException]
...
try {
    Class.forName(dbDriver); //Dynamically loaded jdbc driver class name
    connection = DriverManager.getConnection(urlString, userName, password);
} catch (SQLException e) {
    if (connection != null)
        try { connection.close(); } catch (Exception e2) { ; }
    throw e;
}

What’s happening is that during DBDAO.Connect(), sometimes I’ll get a com.mysql.jdbc.exceptions.jdbc4.CommunicationsException (or some other unexpected exception from whichever jdbc class is loaded). This will not be caught by Connect(), but it will be caught by Execute().

Somehow, this process causes Task’s RollingFileAppender to become closed. The only thing I can think of that’s special to this situation, as opposed to its consistent and stable normal operation, is that the exception being thrown isn’t declared as thrown by Connect(). But I don’t think that should cause a log4j Appender to close.

So my question is, what could be causing this appender to unexpectedly close in methods that have nothing to do with its configuration?

–Edit–
It looks like I’ve been misdirected entirely; the problem is somewhere in the interactions between Quartz, which I was using to have TaskPoller fire every minute, and log4j. I don’t entirely understand its cause yet, but [this solution][1] seems to solve this problem. It just didn’t manifest itself as an observed problem until now, so I thought it had something to do with what was happening recently.

Answer 1

The real cause of this problem is an interaction between the Quartz scheduler and the way I was using log4j. It turns out, if you modify log4j’s properties (which I was doing by calling fileAppender.setFile(fileName) and fileAppender.activateOptions()) on a Quartz worker thread (even if Quartz is configured to only have a single thread running at a time), things break down. This is fixed by reloading the log4j properties on each new instance of the worker thread before using it, which I accomplished like so:

[Task() Constructor]
Properties props = new Properties();
URL url = ClassLoader.getSystemResource("log4j.properties");
try {
    props.load(url.openStream());
    PropertyConfigurator.configure(props);
} catch (Exception e) {
    //The logger that never got renamed never stopped working.
    Logger.getLogger(TaskPoller.class).error("Diagnostics!");
}
logger = Logger.getLogger(Task.class);