Bug 4913 - org.apache.log4j.helpers.FileWatchdog should allow external interrupt()
Summary: org.apache.log4j.helpers.FileWatchdog should allow external interrupt()
Status: REOPENED
Alias: None
Product: Log4j - Now in Jira
Classification: Unclassified
Component: Other (show other bugs)
Version: 1.2.18
Hardware: All All
: P3 minor
Target Milestone: 1.2.18
Assignee: log4j-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-11-16 02:27 UTC by J
Modified: 2014-08-29 11:44 UTC (History)
4 users (show)



Attachments
Webapp to demonstrate the filewatchdog leak (430.41 KB, application/octet-stream)
2012-05-01 18:02 UTC, Tom W
Details
Patch to end FileWatchdog threads when log4j is shut down (6.95 KB, patch)
2012-07-24 04:55 UTC, Pete Feltham
Details | Diff
Terminate the FileWatchDog threads from PropertyConfigurator. (387.38 KB, application/octet-stream)
2014-08-27 13:11 UTC, Roberto AGOSTINO
Details

Note You need to log in before you can comment on or make changes to this bug.
Description J 2001-11-16 02:27:11 UTC
It is impossible to interrupt() a FileWatchdog from outside.
In method run the catch does nothing and should be enhanced by two lines:

  public
  void run() {    
    while(!interrupted) {
      try {
	Thread.currentThread().sleep(delay);
      } catch(InterruptedException e) {
	// no interruption expected
        interrupted = true; // to be added!
        break;              // to be added!
      }
      checkAndConfigure();
    }
  }
Comment 1 Ceki Gulcu 2002-04-25 21:56:15 UTC
The Watchdog architecture will be revisited in log4j 1.3.
Comment 2 Tom W 2012-05-01 18:02:29 UTC
Created attachment 28705 [details]
Webapp to demonstrate the filewatchdog leak
Comment 3 Tom W 2012-05-01 18:03:18 UTC
Ten years on, this is still an issue. I've attached a test case to reproduce the problem, and hopefully accelerate a fix.

The test case is a webapp that I deploy to Tomcat (v7.0.26 in my case) and configures logging. The webapp can be undeployed, but results in a leak because Log4j's Filewatchdog thread is still running, despite the explicit call to LogManager.shutdown() in the ContextListener.

To Reproduce:
1) Install Tomcat with the manager application (not covered here)
2) Build the attached webapp (Ant)
3) Deploy the LeakyWeb.war file to Tomcat, either via Tomcat's manager application, or by dropping the war file into the "webapps" directory.
4) [Optional] Visit http://localhost:8080/LeakyWeb to view the "Success" method.
5) Use Tomcat's manager application to undeploy the webapp.
5a) Note this error message from Tcomat:

May 1, 2012 11:43:08 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/LeakyWeb] appears to have started a thread named [FileWatchdog] but has failed to stop it. This is very likely to create a memory leak.

6) Alternatively, press the "Find Leaks" button in Tomcat's manager application to see the same information.


DESIRED OUTCOME:
Invoking LogManager.shutdown() should interrupt and shut down any watchdog threads that were started by the associated configurer (PropertyConfigurer in this case.)

Naturally this same problem applies to the XML config files as well.
Comment 4 grobmeier 2012-05-01 19:35:20 UTC
wow... ten years and seems as it could be fixed with 2 lines?
When I ever manage to release 1.2.17 I will put this issue on my list for 1.2.18
Comment 5 Tom W 2012-05-01 21:24:36 UTC
The two-line change is a good start, but wouldn't cause the watchdog threads to stop when LogManager.shutdown() is invoked.
Comment 6 grobmeier 2012-05-02 05:44:50 UTC
Thanks. All suggestions etc from your side welcome.

I will look at the shutdown method pretty soonish as I suspect it should clear the MDC stuff too. I can then try to dig into the filewatchdog too.

Anyway, if you want to help, you are welcome :-)
Comment 7 J 2012-05-02 08:16:54 UTC
As the originator of this bug I'm very glad to see that someone is working on it after more than ten years ...
And I'll have a look at the old bugs assigned to me.

Jürgen M. Regel, TUI-InfoTec, Hannover, Germany
Comment 8 grobmeier 2012-05-02 08:21:18 UTC
Thank you Jürgen.

Feel free to ping me / us on the log4j-dev mailinglist if you want to discuss.
Comment 9 Pete Feltham 2012-07-24 04:55:23 UTC
Created attachment 29103 [details]
Patch to end FileWatchdog threads when log4j is shut down

I've attached a patch that works for me. Patch is against the 1.2.17 tag in svn.
Comment 10 J 2012-07-31 07:07:44 UTC
As I see in Pete Feltham's  attachment 29103 [details], a solution much better than my quick-and-dirty fix ten years ago has been found. Even if my server, where the problem arose, is still running without changes and issues for some years, I am not able to verify this now and have confidence in your solution. I'll migrate to the new version of log4j when my program has to be changed again.
Comment 11 seansong2004 2013-04-03 19:02:05 UTC
attachment 29103 [details]'s target milestone is 1.2.18. Is there any target release date for 1.2.18?
Comment 12 grobmeier 2013-04-10 05:15:00 UTC
not yet, i hope i can find some time in may
Comment 13 Alexander Kriegisch 2013-08-02 14:06:39 UTC
Please?! 12 years for such a small issue? What is the problem? Is it so hard to commit the patch and retest? How can any developer be so ignorant toward users? The people in my project (I am ta Scrum coach) actually decided to switch from Log4J to LogBack just because of this issue because SEVERE log messages in Tomcat which are created by this blocking thread keep ringing alarm bells in our operations team. They get woken up at night or on weekends whenever this happens during Tomcat shutdown. Compiling out own version of L4J is not an option, so we need to switch to a whole new logging framework.
Comment 14 Alexander Kriegisch 2013-08-02 14:08:40 UTC
Sorry for the typos, I cannot edit my previous message.
Comment 15 Román Wasinger 2014-07-07 15:04:31 UTC
Hi,
Are there any plans of fixing this issue?
Thank you.
Román
Comment 16 Gary Gregory 2014-07-07 15:29:29 UTC
Can you switch to Log4j 2?

Log4j 1 is not getting much attention as all our focus is on 2?
Comment 17 Roberto AGOSTINO 2014-08-27 13:07:17 UTC
Hi all.
I faced out with this problem today and migrating to the log4j 2, is too expensive for me... so I preferred to look the code and try to fix the problem.

So I added a method, that shutdown all FileWatchDog threads, callable from: 

    PropertyConfigurator.shutdown().

For me this works, and so I hope it will for you. Look at the attachment as log4j-1.2.18.jar.

Best regards

R. A.
Comment 18 Roberto AGOSTINO 2014-08-27 13:11:36 UTC
Created attachment 31949 [details]
Terminate the FileWatchDog threads from PropertyConfigurator.

To use the new function, call the PropertyConfigurator.shutdown() before exit from the application.

Note: I suppose you called PropertyConfigurator.configure...(...) at the init of your application.
Comment 19 Roberto AGOSTINO 2014-08-28 06:20:56 UTC
Good morning to all!
I apologize for yesterday's post, but the rush to get a solution, I did not read all the posts and have found the solution to this only after my post. I think the best solution is previously provided, although the one contained in the library provided by me works. 
Have a good day and job. 
R.A.
Comment 20 Gary Gregory 2014-08-28 12:42:54 UTC
Keep in mind that the 1.x line is not actively maintained in favor of concentrating our efforts on 2.x.
Comment 21 Gary Gregory 2014-08-29 11:44:47 UTC
You are correct, version 2.0.2 does not support the properties file format for configuration.