[ https://issues.apache.org/jira/browse/IO-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pascal Schumacher updated IO-535: --------------------------------- Summary: Thread bug in FileAlterationMonitor#stop(int) (was: Thread bug in FileAlterationMonitor) > Thread bug in FileAlterationMonitor#stop(int) > --------------------------------------------- > > 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(500000); > } catch (final InterruptedException e) { > } > }); > t.start(); > t.join(50); > // Ok, we reach this point until 500000ms 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(500000); > } 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 (v7.6.3#76005)