[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)
