logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fenderbosch, Eric" <Eric.Fenderbo...@fedex.com>
Subject RE: Attempted to append to closed appender
Date Tue, 26 Oct 2004 16:14:44 GMT
Our problems (besides this one) w/ log4j and 8.1 have a little more serious, unfortunately.
 As I mentioned before, something is definitely different with threading.  We are getting
hundreds of FileWatchdog threads from configureAndWatch.  They keep accumulating and eventually
crash the app server with an out of memory error.  I've looked at our log4j initialization
code and configureAndWatch really should only be running once per application, or at most
once per EJB/DAO, but it appears that somewhere it is running once per instantiation.  Unfortunately,
tracking this down has been difficult.  Our solution is to remove configureAndWatch from all
application code and use WebLogic's application lifecycle API to perform the initialization.
 Here's the code and deployment descriptor, it might be of use to someone.

/* Created on Oct 8, 2004 */
package com.fedex.cc.applifecycle;

import org.apache.log4j.Logger;
import org.apache.log4j.PropertyConfigurator;

import weblogic.application.ApplicationLifecycleEvent;
import weblogic.application.ApplicationLifecycleListener;

 * @author emf
public class Log4JStartupListener extends ApplicationLifecycleListener {

    private static final String configFilename = "conf/log4j.properties";
    private static final Logger log = Logger.getLogger(Log4JStartupListener.class);

    /** @see weblogic.application.ApplicationLifecycleListener#preStart(weblogic.application.ApplicationLifecycleEvent)
    public void preStart(ApplicationLifecycleEvent evt) {
        String appName = evt.getApplicationContext().getApplicationName();
        log.info("Log4J configured for application " + appName);

Compile that, jar it up and put in APP-INF/lib in your EAR file.  Then add a listener section
to weblogic-application.xml, like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE weblogic-application PUBLIC "-//BEA Systems, Inc.//DTD WebLogic Application 8.1.0//EN"

This has been working well for us.  Several applications still need to be redeployed with
this solution, but the thread count is rising at a slower rate.

-----Original Message-----
From: Tom.Goetze@kp.org [mailto:Tom.Goetze@kp.org]
Sent: Tuesday, October 26, 2004 11:53 AM
To: log4j-user@logging.apache.org
Subject: RE: Attempted to append to closed appender

Ceki's note jogged my memory on my problem, which is likely similar to 

I'm guessing something during your WebLogic upgrade now attempts to use 
Log4j before your configuration takes affect and in Log4j's initialization 
attempts it finds another configuration file which creates an appender 
with the same name as one that you are using and assigns it to the 
rootLogger, but also uses the same appender with another logger. (This is 
likely outside of your control--as it was in my case.)

So, when you reconfigure the rootLogger, it closes (but does not remove 
from all loggers) the appender that you share in name. Since you didn't 
know about the other logger that one of the JAR files includes, you don't 
know to close it or to remove the appender from it.

So, what I was hoping for was the ability to remove any closed appenders 
from the system, but I don't think that was available (the status on the 
appender was not publicly available).

In my case, I need to dynamically change the configuration at startup, so 
using the system property to identify the exact location of a static 
configuration file was not possible for me. It might work for you.

Another possibility for you, would be to change the name of your appender 
and it might go back to working.

Tom Goetze

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message