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