[jira] [Updated] (IO-535) FileAlterationMonitor
[ https://issues.apache.org/jira/browse/IO-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony RAYMOND updated IO-535: --- Description: The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, which forbid application to shutdown unless all `Thread` are exited (if FileAlterationMonitor is part of a DI managed component). This behavior conflict with the method javadoc `@param stopInterval the amount of time in milliseconds to wait for the thread to finish.` ### Simple example to understand Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); // Ok, we reach this point until 50ms are elapsed, but the thread is still alive. // because Thread#join(int) does not kill the thread. And the thread remains alive. Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); t.interupt(); // Thread is exited In this case, we waited the given time BEFORE exiting the `Thread`, as described in the javadoc, and the `Thread` is now finished and killed. was: The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, which forbid application to shutdown unless all `Thread` are exited (if FileAlterationMonitor is part of a DI managed component). This behavior conflict with the method javadoc `@param stopInterval the amount of time in milliseconds to wait for the thread to finish.` ### Simple exemple to understand ```java Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); // Ok, we reach this point until 50ms are elapsed, but the thread is still alive. // because Thread#join(int) does not kill the thread. And the thread remains alive. ``` ```java Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); t.interupt(); // Thread is exited ``` In this case, we waited the given time BEFORE exiting the `Thread`, as described in the javadoc, and the `Thread` is now finished and killed. > FileAlterationMonitor > - > > Key: IO-535 > URL: https://issues.apache.org/jira/browse/IO-535 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.5 > Environment: Components managed by a DI Framework >Reporter: Anthony RAYMOND >Priority: Critical > Labels: easyfix, patch, performance > Original Estimate: 1h > Remaining Estimate: 1h > > The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, > which forbid application to shutdown unless all `Thread` are exited (if > FileAlterationMonitor is part of a DI managed component). > This behavior conflict with the method javadoc `@param stopInterval the > amount of time in milliseconds to wait for the thread to finish.` > ### Simple example to understand > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); >// Ok, we reach this point until 50ms are elapsed, but the thread is > still alive. >// because Thread#join(int) does not kill the thread. And the thread > remains alive. > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); > t.interupt(); >// Thread is exited > In this case, we waited the given time BEFORE exiting the `Thread`, as > described in the javadoc, and the `Thread` is now finished and killed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IO-535) FileAlterationMonitor
[ https://issues.apache.org/jira/browse/IO-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony RAYMOND updated IO-535: --- Description: The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, which forbid application to shutdown unless all `Thread` are exited (if FileAlterationMonitor is part of a DI managed component). This behavior conflict with the method javadoc `@param stopInterval the amount of time in milliseconds to wait for the thread to finish.` hn.5 Simple example to understand {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); // Ok, we reach this point until 50ms are elapsed, but the thread is still alive. // because Thread#join(int) does not kill the thread. And the thread remains alive. {code} {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); t.interupt(); // Thread is exited {code} In this case, we waited the given time BEFORE exiting the `Thread`, as described in the javadoc, and the `Thread` is now finished and killed. was: The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, which forbid application to shutdown unless all `Thread` are exited (if FileAlterationMonitor is part of a DI managed component). This behavior conflict with the method javadoc `@param stopInterval the amount of time in milliseconds to wait for the thread to finish.` ### Simple example to understand {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); // Ok, we reach this point until 50ms are elapsed, but the thread is still alive. // because Thread#join(int) does not kill the thread. And the thread remains alive. {code} {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); t.interupt(); // Thread is exited {code} In this case, we waited the given time BEFORE exiting the `Thread`, as described in the javadoc, and the `Thread` is now finished and killed. > FileAlterationMonitor > - > > Key: IO-535 > URL: https://issues.apache.org/jira/browse/IO-535 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.5 > Environment: Components managed by a DI Framework >Reporter: Anthony RAYMOND >Priority: Critical > Labels: easyfix, patch, performance > Original Estimate: 1h > Remaining Estimate: 1h > > The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, > which forbid application to shutdown unless all `Thread` are exited (if > FileAlterationMonitor is part of a DI managed component). > This behavior conflict with the method javadoc `@param stopInterval the > amount of time in milliseconds to wait for the thread to finish.` > hn.5 Simple example to understand > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); >// Ok, we reach this point until 50ms are elapsed, but the thread is > still alive. >// because Thread#join(int) does not kill the thread. And the thread > remains alive. > {code} > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); > t.interupt(); >// Thread is exited > {code} > In this case, we waited the given time BEFORE exiting the `Thread`, as > described in the javadoc, and the `Thread` is now finished and killed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IO-535) FileAlterationMonitor
[ https://issues.apache.org/jira/browse/IO-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony RAYMOND updated IO-535: --- Description: The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, which forbid application to shutdown unless all `Thread` are exited (if FileAlterationMonitor is part of a DI managed component). This behavior conflict with the method javadoc `@param stopInterval the amount of time in milliseconds to wait for the thread to finish.` ### Simple example to understand {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); // Ok, we reach this point until 50ms are elapsed, but the thread is still alive. // because Thread#join(int) does not kill the thread. And the thread remains alive. {code} {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); t.interupt(); // Thread is exited {code} In this case, we waited the given time BEFORE exiting the `Thread`, as described in the javadoc, and the `Thread` is now finished and killed. was: The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, which forbid application to shutdown unless all `Thread` are exited (if FileAlterationMonitor is part of a DI managed component). This behavior conflict with the method javadoc `@param stopInterval the amount of time in milliseconds to wait for the thread to finish.` ### Simple example to understand Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); // Ok, we reach this point until 50ms are elapsed, but the thread is still alive. // because Thread#join(int) does not kill the thread. And the thread remains alive. Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); t.interupt(); // Thread is exited In this case, we waited the given time BEFORE exiting the `Thread`, as described in the javadoc, and the `Thread` is now finished and killed. > FileAlterationMonitor > - > > Key: IO-535 > URL: https://issues.apache.org/jira/browse/IO-535 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.5 > Environment: Components managed by a DI Framework >Reporter: Anthony RAYMOND >Priority: Critical > Labels: easyfix, patch, performance > Original Estimate: 1h > Remaining Estimate: 1h > > The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, > which forbid application to shutdown unless all `Thread` are exited (if > FileAlterationMonitor is part of a DI managed component). > This behavior conflict with the method javadoc `@param stopInterval the > amount of time in milliseconds to wait for the thread to finish.` > ### Simple example to understand > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); >// Ok, we reach this point until 50ms are elapsed, but the thread is > still alive. >// because Thread#join(int) does not kill the thread. And the thread > remains alive. > {code} > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); > t.interupt(); >// Thread is exited > {code} > In this case, we waited the given time BEFORE exiting the `Thread`, as > described in the javadoc, and the `Thread` is now finished and killed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IO-535) FileAlterationMonitor
[ https://issues.apache.org/jira/browse/IO-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony RAYMOND updated IO-535: --- Description: The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, which forbid application to shutdown unless all `Thread` are exited (if FileAlterationMonitor is part of a DI managed component). This behavior conflict with the method javadoc `@param stopInterval the amount of time in milliseconds to wait for the thread to finish.` h5 Simple example to understand {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); // Ok, we reach this point until 50ms are elapsed, but the thread is still alive. // because Thread#join(int) does not kill the thread. And the thread remains alive. {code} {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); t.interupt(); // Thread is exited {code} In this case, we waited the given time BEFORE exiting the `Thread`, as described in the javadoc, and the `Thread` is now finished and killed. was: The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, which forbid application to shutdown unless all `Thread` are exited (if FileAlterationMonitor is part of a DI managed component). This behavior conflict with the method javadoc `@param stopInterval the amount of time in milliseconds to wait for the thread to finish.` hn5 Simple example to understand {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); // Ok, we reach this point until 50ms are elapsed, but the thread is still alive. // because Thread#join(int) does not kill the thread. And the thread remains alive. {code} {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); t.interupt(); // Thread is exited {code} In this case, we waited the given time BEFORE exiting the `Thread`, as described in the javadoc, and the `Thread` is now finished and killed. > FileAlterationMonitor > - > > Key: IO-535 > URL: https://issues.apache.org/jira/browse/IO-535 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.5 > Environment: Components managed by a DI Framework >Reporter: Anthony RAYMOND >Priority: Critical > Labels: easyfix, patch, performance > Original Estimate: 1h > Remaining Estimate: 1h > > The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, > which forbid application to shutdown unless all `Thread` are exited (if > FileAlterationMonitor is part of a DI managed component). > This behavior conflict with the method javadoc `@param stopInterval the > amount of time in milliseconds to wait for the thread to finish.` > h5 Simple example to understand > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); >// Ok, we reach this point until 50ms are elapsed, but the thread is > still alive. >// because Thread#join(int) does not kill the thread. And the thread > remains alive. > {code} > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); > t.interupt(); >// Thread is exited > {code} > In this case, we waited the given time BEFORE exiting the `Thread`, as > described in the javadoc, and the `Thread` is now finished and killed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IO-535) FileAlterationMonitor
[ https://issues.apache.org/jira/browse/IO-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony RAYMOND updated IO-535: --- Description: The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, which forbid application to shutdown unless all `Thread` are exited (if FileAlterationMonitor is part of a DI managed component). This behavior conflict with the method javadoc `@param stopInterval the amount of time in milliseconds to wait for the thread to finish.` h5. Simple example to understand {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); // Ok, we reach this point until 50ms are elapsed, but the thread is still alive. // because Thread#join(int) does not kill the thread. And the thread remains alive. {code} {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); t.interupt(); // Thread is exited {code} In this case, we waited the given time BEFORE exiting the `Thread`, as described in the javadoc, and the `Thread` is now finished and killed. was: The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, which forbid application to shutdown unless all `Thread` are exited (if FileAlterationMonitor is part of a DI managed component). This behavior conflict with the method javadoc `@param stopInterval the amount of time in milliseconds to wait for the thread to finish.` h5 Simple example to understand {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); // Ok, we reach this point until 50ms are elapsed, but the thread is still alive. // because Thread#join(int) does not kill the thread. And the thread remains alive. {code} {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); t.interupt(); // Thread is exited {code} In this case, we waited the given time BEFORE exiting the `Thread`, as described in the javadoc, and the `Thread` is now finished and killed. > FileAlterationMonitor > - > > Key: IO-535 > URL: https://issues.apache.org/jira/browse/IO-535 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.5 > Environment: Components managed by a DI Framework >Reporter: Anthony RAYMOND >Priority: Critical > Labels: easyfix, patch, performance > Original Estimate: 1h > Remaining Estimate: 1h > > The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, > which forbid application to shutdown unless all `Thread` are exited (if > FileAlterationMonitor is part of a DI managed component). > This behavior conflict with the method javadoc `@param stopInterval the > amount of time in milliseconds to wait for the thread to finish.` > h5. Simple example to understand > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); >// Ok, we reach this point until 50ms are elapsed, but the thread is > still alive. >// because Thread#join(int) does not kill the thread. And the thread > remains alive. > {code} > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); > t.interupt(); >// Thread is exited > {code} > In this case, we waited the given time BEFORE exiting the `Thread`, as > described in the javadoc, and the `Thread` is now finished and killed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IO-535) FileAlterationMonitor
[ https://issues.apache.org/jira/browse/IO-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony RAYMOND updated IO-535: --- Description: The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, which forbid application to shutdown unless all `Thread` are exited (if FileAlterationMonitor is part of a DI managed component). This behavior conflict with the method javadoc `@param stopInterval the amount of time in milliseconds to wait for the thread to finish.` hn5 Simple example to understand {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); // Ok, we reach this point until 50ms are elapsed, but the thread is still alive. // because Thread#join(int) does not kill the thread. And the thread remains alive. {code} {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); t.interupt(); // Thread is exited {code} In this case, we waited the given time BEFORE exiting the `Thread`, as described in the javadoc, and the `Thread` is now finished and killed. was: The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, which forbid application to shutdown unless all `Thread` are exited (if FileAlterationMonitor is part of a DI managed component). This behavior conflict with the method javadoc `@param stopInterval the amount of time in milliseconds to wait for the thread to finish.` hn.5 Simple example to understand {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); // Ok, we reach this point until 50ms are elapsed, but the thread is still alive. // because Thread#join(int) does not kill the thread. And the thread remains alive. {code} {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); t.interupt(); // Thread is exited {code} In this case, we waited the given time BEFORE exiting the `Thread`, as described in the javadoc, and the `Thread` is now finished and killed. > FileAlterationMonitor > - > > Key: IO-535 > URL: https://issues.apache.org/jira/browse/IO-535 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.5 > Environment: Components managed by a DI Framework >Reporter: Anthony RAYMOND >Priority: Critical > Labels: easyfix, patch, performance > Original Estimate: 1h > Remaining Estimate: 1h > > The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, > which forbid application to shutdown unless all `Thread` are exited (if > FileAlterationMonitor is part of a DI managed component). > This behavior conflict with the method javadoc `@param stopInterval the > amount of time in milliseconds to wait for the thread to finish.` > hn5 Simple example to understand > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); >// Ok, we reach this point until 50ms are elapsed, but the thread is > still alive. >// because Thread#join(int) does not kill the thread. And the thread > remains alive. > {code} > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); > t.interupt(); >// Thread is exited > {code} > In this case, we waited the given time BEFORE exiting the `Thread`, as > described in the javadoc, and the `Thread` is now finished and killed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IO-535) FileAlterationMonitor
[ https://issues.apache.org/jira/browse/IO-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony RAYMOND updated IO-535: --- Description: The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, which forbid application to shutdown unless all `Thread` are exited (if FileAlterationMonitor is part of a DI managed component). This behavior conflict with the method javadoc `@param stopInterval the amount of time in milliseconds to wait for the thread to finish.` h5. Simple example to understand Bad behavior {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); // Ok, we reach this point until 50ms are elapsed, but the thread is still alive. // because Thread#join(int) does not kill the thread. And the thread remains alive. {code} Good behavior {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); t.interupt(); // Thread is exited {code} In this case, we waited the given time BEFORE exiting the `Thread`, as described in the javadoc, and the `Thread` is now finished and killed. was: The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, which forbid application to shutdown unless all `Thread` are exited (if FileAlterationMonitor is part of a DI managed component). This behavior conflict with the method javadoc `@param stopInterval the amount of time in milliseconds to wait for the thread to finish.` h5. Simple example to understand {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); // Ok, we reach this point until 50ms are elapsed, but the thread is still alive. // because Thread#join(int) does not kill the thread. And the thread remains alive. {code} {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); t.interupt(); // Thread is exited {code} In this case, we waited the given time BEFORE exiting the `Thread`, as described in the javadoc, and the `Thread` is now finished and killed. > FileAlterationMonitor > - > > Key: IO-535 > URL: https://issues.apache.org/jira/browse/IO-535 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.5 > Environment: Components managed by a DI Framework >Reporter: Anthony RAYMOND >Priority: Critical > Labels: easyfix, patch, performance > Original Estimate: 1h > Remaining Estimate: 1h > > The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, > which forbid application to shutdown unless all `Thread` are exited (if > FileAlterationMonitor is part of a DI managed component). > This behavior conflict with the method javadoc `@param stopInterval the > amount of time in milliseconds to wait for the thread to finish.` > h5. Simple example to understand > Bad behavior > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); >// Ok, we reach this point until 50ms are elapsed, but the thread is > still alive. >// because Thread#join(int) does not kill the thread. And the thread > remains alive. > {code} > Good behavior > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); > t.interupt(); >// Thread is exited > {code} > In this case, we waited the given time BEFORE exiting the `Thread`, as > described in the javadoc, and the `Thread` is now finished and killed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IO-535) FileAlterationMonitor
[ https://issues.apache.org/jira/browse/IO-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony RAYMOND updated IO-535: --- Remaining Estimate: 5m (was: 1h) Original Estimate: 5m (was: 1h) > FileAlterationMonitor > - > > Key: IO-535 > URL: https://issues.apache.org/jira/browse/IO-535 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.5 > Environment: Components managed by a DI Framework >Reporter: Anthony RAYMOND >Priority: Critical > Labels: easyfix, patch, performance > Original Estimate: 5m > Remaining Estimate: 5m > > The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, > which forbid application to shutdown unless all `Thread` are exited (if > FileAlterationMonitor is part of a DI managed component). > This behavior conflict with the method javadoc `@param stopInterval the > amount of time in milliseconds to wait for the thread to finish.` > h5. Simple example to understand > Bad behavior > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); >// Ok, we reach this point until 50ms are elapsed, but the thread is > still alive. >// because Thread#join(int) does not kill the thread. And the thread > remains alive. > {code} > Good behavior > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); > t.interupt(); >// Thread is exited > {code} > In this case, we waited the given time BEFORE exiting the `Thread`, as > described in the javadoc, and the `Thread` is now finished and killed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IO-535) FileAlterationMonitor
[ https://issues.apache.org/jira/browse/IO-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony RAYMOND updated IO-535: --- Description: The thread in FileAlterationMonitor wasn't stopped by the `stop(int)` method, which forbid application to shutdown until all `Thread` are exited (if FileAlterationMonitor is part of a DI managed component). This behavior conflict with the method javadoc `@param stopInterval the amount of time in milliseconds to wait for the thread to finish.` h5. Simple example to understand Bad behavior {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); // Ok, we reach this point until 50ms are elapsed, but the thread is still alive. // because Thread#join(int) does not kill the thread. And the thread remains alive. {code} Good behavior {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); t.interupt(); // Thread is exited {code} In this case, we waited the given time BEFORE exiting the `Thread`, as described in the javadoc, and the `Thread` is now finished and killed. was: The thread if FileAlterationMonitor wasn't stopped by the `stop(int)` method, which forbid application to shutdown unless all `Thread` are exited (if FileAlterationMonitor is part of a DI managed component). This behavior conflict with the method javadoc `@param stopInterval the amount of time in milliseconds to wait for the thread to finish.` h5. Simple example to understand Bad behavior {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); // Ok, we reach this point until 50ms are elapsed, but the thread is still alive. // because Thread#join(int) does not kill the thread. And the thread remains alive. {code} Good behavior {code:java} Thread t = new Thread(() -> { try { Thread.sleep(50); } catch (final InterruptedException e) { } }); t.start(); t.join(50); t.interupt(); // Thread is exited {code} In this case, we waited the given time BEFORE exiting the `Thread`, as described in the javadoc, and the `Thread` is now finished and killed. Component/s: Utilities > FileAlterationMonitor > - > > Key: IO-535 > URL: https://issues.apache.org/jira/browse/IO-535 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.5 > Environment: Components managed by a DI Framework >Reporter: Anthony RAYMOND >Priority: Critical > Labels: easyfix, patch, performance > Original Estimate: 5m > Remaining Estimate: 5m > > The thread in FileAlterationMonitor wasn't stopped by the `stop(int)` method, > which forbid application to shutdown until all `Thread` are exited (if > FileAlterationMonitor is part of a DI managed component). > This behavior conflict with the method javadoc `@param stopInterval the > amount of time in milliseconds to wait for the thread to finish.` > h5. Simple example to understand > Bad behavior > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); >// Ok, we reach this point until 50ms are elapsed, but the thread is > still alive. >// because Thread#join(int) does not kill the thread. And the thread > remains alive. > {code} > Good behavior > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); > t.interupt(); >// Thread is exited > {code} > In this case, we waited the given time BEFORE exiting the `Thread`, as > described in the javadoc, and the `Thread` is now finished and killed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IO-535) FileAlterationMonitor
[ https://issues.apache.org/jira/browse/IO-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony RAYMOND updated IO-535: --- External issue URL: https://github.com/apache/commons-io/pulls > FileAlterationMonitor > - > > Key: IO-535 > URL: https://issues.apache.org/jira/browse/IO-535 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.5 > Environment: Components managed by a DI Framework >Reporter: Anthony RAYMOND >Priority: Critical > Labels: easyfix, patch, performance > Original Estimate: 5m > Remaining Estimate: 5m > > The thread in FileAlterationMonitor wasn't stopped by the `stop(int)` method, > which forbid application to shutdown until all `Thread` are exited (if > FileAlterationMonitor is part of a DI managed component). > This behavior conflict with the method javadoc `@param stopInterval the > amount of time in milliseconds to wait for the thread to finish.` > h5. Simple example to understand > Bad behavior > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); >// Ok, we reach this point until 50ms are elapsed, but the thread is > still alive. >// because Thread#join(int) does not kill the thread. And the thread > remains alive. > {code} > Good behavior > {code:java} > Thread t = new Thread(() -> { > try { > Thread.sleep(50); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); > t.interupt(); >// Thread is exited > {code} > In this case, we waited the given time BEFORE exiting the `Thread`, as > described in the javadoc, and the `Thread` is now finished and killed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)