[
https://issues.apache.org/jira/browse/IO-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved IO-259.
--------------------------------
Resolution: Fixed
Fix Version/s: 2.1
Assignee: Niall Pemberton
Good suggestions - I added a stop(long) method and if you specify a negative
value it stops immediately.
http://svn.apache.org/viewvc?view=revision&revision=1080843
> 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
> Assignee: Niall Pemberton
> Fix For: 2.1
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
