[jira] Created: (IO-259) FileAlterationMonitor.stop(boolean allowIntervalToFinish)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (IO-259) FileAlterationMonitor.stop(boolean allowIntervalToFinish)

ASF GitHub Bot (Jira)
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.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (IO-259) FileAlterationMonitor.stop(boolean allowIntervalToFinish)

ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/IO-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Checkoway updated IO-259:
-----------------------------

    Attachment: IO-259.patch

Patch attached, adding the second version of FileAlterationMonitor.stop(boolean).  Default behavior is for stop() to call stop(true).  But users can override that by calling stop(false) explicitly.

Please add this to trunk and the next release.  Thanks!!

FWIW, I already have an ICLA on file for my contributions to other projects.

> 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (IO-259) FileAlterationMonitor.stop(boolean allowIntervalToFinish)

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

    [ https://issues.apache.org/jira/browse/IO-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983806#action_12983806 ]

Dan Checkoway commented on IO-259:
----------------------------------

Another variation would be to have FileAlterationMonitor.stop(long millis), and millis would be passed to thread.join().  That way the caller could specify the max allowable wait time for the join.  NOTE that 0 means wait forever according to the JDK, so you'd have to pass 1 (or would -1 work?) if you wanted it to wait as little time as possible.

> 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Resolved: (IO-259) FileAlterationMonitor.stop(boolean allowIntervalToFinish)

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ 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
Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (IO-259) FileAlterationMonitor.stop(boolean allowIntervalToFinish)

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

    [ https://issues.apache.org/jira/browse/IO-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005981#comment-13005981 ]

Dan Checkoway commented on IO-259:
----------------------------------

@Niall, thanks!  Much appreciated.  Looking forward to 2.1.

> 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
Reply | Threaded
Open this post in threaded view
|

[jira] [Closed] (IO-259) FileAlterationMonitor.stop(boolean allowIntervalToFinish)

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/IO-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary D. Gregory closed IO-259.
------------------------------


Closing, we released version 2.1.
               

> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira