logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "McDonnell, Colm (MLIM)" <colm_mcdonn...@ml.com>
Subject RE: RollingFileAppender issue
Date Fri, 03 Dec 2004 17:31:06 GMT
Thanks for the info - I am calling LogManager.shutdown() in my ServletContextListener's contextDestroyed()
method. When I attempt to redeploy the application under WebLogic 8.1 the shutdown method
throws a NoClassDefFound exception for org.apache.log4j.helpers.NullEnumeration. However when
I stop the application (as distinct from redeploy) it works fine. Also it works fine for both
stop and restart operations under Tomcat 5.x. 

My next step is to figure out how/why WebLogic treats redeploy as something other than stop
+ start.

Thanks for your help.


-----Original Message-----
From: Ceki Gülcü [mailto:ceki@qos.ch] 
Sent: 03 December 2004 10:29
To: Log4J Users List; log4j-user@logging.apache.org
Subject: Re: RollingFileAppender issue



At 06:27 PM 12/2/2004, McDonnell, Colm (MLIM) wrote:

[cut]

>The problem arises in org.apache.log4j.RollingFileAppender.rollOver() at
>line 139 ( file.renameTo(target); ), using FileMon in parallel with
>debugging the Log4J code I discovered that the renameTo instruction
>fails on a shared access violation, then when I looked at this file
>using ProcessExplorer I discovered that WebLogic had multiple file
>handles open to the same file. Further investigation showed that these
>files are left open when I stop and restart the application, in other
>words the open file handle which log4j has on the log file is not closed
>when the application is stopped. Killing the WebLogic process causes all
>file handles to be closed and we are back to the situation where the
>RollingFileAppender works because the only open file handle is the one
>it is currently using. However, the next time the application is
>restarted the issue reappears and so on ....

Log4j will release its resource when LogManager.shutdown() is called. A 
good place to invoke this method is in 
ServletContextListener.contextDestroyed() method.


>The same RollingFileAppender configuration works with Tomcat (on Windows
>2000/XP and Solaris) and with WebLogic 6.1/8.1 (on UNIX). So, it seems
>like it might be related to some assumptions log4j makes about how the
>application (or its container) will close file handles which conflict
>with what WebLogic actually does on the Windows platform. And yet, if
>this was true surely I would have found details of this issue in the
>mailing lists and on Google etc.
>
>Anyway, I am aware that this may not be the best place to post this
>issue however I am hoping that someone on this list may have encountered
>this issue previously. In particular I am interested to know how log4j
>expects an open file handle to be closed, the only code I have found in
>the code base is the closeFile() method on FileAppender and its sub
>classes however this is not intended to be called on application
>shutdown so I am assuming that log4j assumes that the application will
>be responsible for closing any file handles.

o.a.log4j.LogManager.shutdown() takes care of releasing resources.


-- 
Ceki Gülcü

  The complete log4j manual:  http://qos.ch/eclm
  Professional log4j support: http://qos.ch/log4jSupport  



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org 
--------------------------------------------------------
 
If you are not an intended recipient of this e-mail, please notify the sender, delete it and
do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important
additional terms relating to this e-mail.     http://www.ml.com/email_terms/ 
--------------------------------------------------------
 

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


Mime
View raw message