[
https://issues.apache.org/jira/browse/CURATOR-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Cooper updated CURATOR-353:
---------------------------------
Description:
In our example, we've got a PathChildrenCache and PersistentNode sharing the
same executor.
This interacts badly with interrupts - when `PathChildrenCache` is closed, this
calls `CloseableExecutorService.close()`, which interrupts all the current
pending tasks via `Future.cancel(true)`.
If `PersistentNode` is then closed, there's a chance that the `deleteNode()`
will happen on a thread on the shared executor that was interrupted by the
closing executor service. This throws `InterruptedException`, which is caught
and rethrown as an `IOException`. This results in spurious failures in our
tests when the `close` randomly throws `IOException`.
I'm not sure that re-throwing an `InterruptedException` as an `IOException` is
a good idea - there's already code that re-sets the interrupt status on the
thread, should it just leave it at that? Else it looks like the thread has been
interrupted twice.
was:
In our example, we've got a PathChildrenCache and PersistentNode sharing the
same executor.
This interacts badly with interrupts - when `PathChildrenCache` is closed, this
calls `CloseableExecutorService.close()`, which interrupts all the current
pending tasks via `Future.cancel(true)`.
If `PersistentNode` is then closed, there's a chance that the `deleteNode()`
will happen on a thread on the shared executor that was interrupted by the
closing executor service. This throws `InterruptedException`, which is caught
and rethrown as an `IOException`. This results in spurious failures in our
tests when the `close` randomly throws `IOException`
> PathChildrenCache and PersistentNode interrupt each other if sharing the same
> executor
> --------------------------------------------------------------------------------------
>
> Key: CURATOR-353
> URL: https://issues.apache.org/jira/browse/CURATOR-353
> Project: Apache Curator
> Issue Type: Bug
> Affects Versions: 2.11.0
> Reporter: Simon Cooper
> Assignee: Jordan Zimmerman
> Priority: Minor
>
> In our example, we've got a PathChildrenCache and PersistentNode sharing the
> same executor.
> This interacts badly with interrupts - when `PathChildrenCache` is closed,
> this calls `CloseableExecutorService.close()`, which interrupts all the
> current pending tasks via `Future.cancel(true)`.
> If `PersistentNode` is then closed, there's a chance that the `deleteNode()`
> will happen on a thread on the shared executor that was interrupted by the
> closing executor service. This throws `InterruptedException`, which is caught
> and rethrown as an `IOException`. This results in spurious failures in our
> tests when the `close` randomly throws `IOException`.
> I'm not sure that re-throwing an `InterruptedException` as an `IOException`
> is a good idea - there's already code that re-sets the interrupt status on
> the thread, should it just leave it at that? Else it looks like the thread
> has been interrupted twice.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
