[
https://issues.jboss.org/browse/ISPN-6424?page=com.atlassian.jira.plugin....
]
William Burns commented on ISPN-6424:
-------------------------------------
[~dan.berindei] I was fully aware of that exception, and it is only part of the issue.
The core problem is when the following happens
# n1 userthread - distributed executor submits a task
# n1 userthread - task is interrupted
# n1 userthread - distributed executor sends cancellation command to remote node
# n2 remote thread - interrupts task and send back the exception you just mentioned
# n1 remote thread - receives exception response
# n1 remote thread - sets exception status on future
# n1 user thread tries to interrupt future but cannot since it was completed with
exception
Unless you are saying to know somehow in the n2 remote thread that it was caused due
solely to an interrupt and instead send back some kind of cancelled response? But in that
case we will mess up other exception call stacks if the cache was actually shut down.
Thus my change is to make sure to set the cancelled status on the future before we even
send the remote cancellation which prevents this timing issue.
Distributed Executor get can propagate exception if interrupt returns
before cancellation
-----------------------------------------------------------------------------------------
Key: ISPN-6424
URL:
https://issues.jboss.org/browse/ISPN-6424
Project: Infinispan
Issue Type: Bug
Components: Distributed Execution and Map/Reduce
Reporter: William Burns
Assignee: William Burns
Fix For: 9.0.0.Alpha1
This can cause get method to return an exception of the operation being interrupted
instead of a CancellationException as it should.
This causes a test failure
http://ci.infinispan.org/viewLog.html?buildId=37756&tab=buildResultsD...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)