[
https://issues.apache.org/jira/browse/CURATOR-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15545781#comment-15545781
]
Jordan Zimmerman commented on CURATOR-353:
------------------------------------------
A test and/or PR would be appreciated if possible.
> 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)
