curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Cooper (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CURATOR-353) PathChildrenCache and PersistentNode interrupt each other if sharing the same executor
Date Tue, 04 Oct 2016 15:39:20 GMT

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

Mime
View raw message