FileAlterationMonitor.stop(boolean allowIntervalToFinish)
---------------------------------------------------------
Key: IO-259
URL: https://issues.apache.org/jira/browse/IO-259
Project: Commons IO
Issue Type: Improvement
Reporter: Dan Checkoway
Attachments: IO-259.patch
I'm a long-time user of commons-io, but I just started using
FileAlterationMonitor the other day. I have a bean in a Spring application
context that constructs a FileAlterationMonitor, and it sets the ThreadFactory
to an instance that creates daemon threads. At context shutdown, my bean calls
.stop() on the monitor.
The problem is that .stop() currently honors the Thread.sleep(interval), in
that it does a nice friendly thread.join(). If you set your interval high
enough, your "graceful app shutdown" is going to sit there waiting a while.
Compounding things is that I have *seven* FileAlterationMonitors in my app, all
of which run with a 10-second sleep time. So at graceful shutdown time, I'm
facing a delay of up to 70 seconds...lame!
So I stopped calling .stop() and since the ThreadFactory created daemon
threads, shutdown is quick. But...
I'm running inside tomcat, and when it shuts down it looks for leaks. And of
course it finds a handful of my threads and complains, such as:
SEVERE: The web application [/my-webapp] appears to have started a thread named
[FileUpdateMonitor-/path/to/my/file.ext] but has failed to stop it. This is
very likely to create a memory leak.
So what I'm suggesting is an alternate version of FileAlterationMonitor.stop()
that takes "boolean allowIntervalToFinish". The default behavior won't change
(for backward compatibility). But if you explicitly call .stop(false), then it
will interrupt the sleeping thread immediately. That thread wakes up, sees
that running=false, and finishes up immediately.
Patch will be attached in a sec...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
