ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ozerov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-4480) Incorrect cancellation semantics in IgniteFuture
Date Mon, 26 Dec 2016 12:34:58 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15778258#comment-15778258

Vladimir Ozerov commented on IGNITE-4480:

Right, but {{cancel()}} should always lead to {{CancelledException}} from user perspective
always. You may or may not perform some special actions in response to cancel, but from the
outside behavior must be consistent.
This topic was discussed on concurrency-interest multiple times. And bottom line is that correct
design is when execution is decoupled from cancellation handling. This is what I essentially

> Incorrect cancellation semantics in IgniteFuture
> ------------------------------------------------
>                 Key: IGNITE-4480
>                 URL: https://issues.apache.org/jira/browse/IGNITE-4480
>             Project: Ignite
>          Issue Type: Task
>          Components: general
>    Affects Versions: 1.8
>            Reporter: Vladimir Ozerov
>             Fix For: 2.0
> *Problem*
> Normally, if user invoke "cancel()" on future, he expects that it will be completed immediately.
E.g. this is how JDK {{CompletableFuture}} works. However, this is not the case for Ignite
- we inform user about cancellation through flag, which is also not set properly in most cases.
> *Solution*
> 1) {{cancel()}} must complete future with special "CancellationException" immediately.
> 2) {{isCancelled()}} method should be either removed or deprecated.
> 3{ We should add {{isCompletedExceptionally()}} method which will return {{true}} in
case future was completed with any kind of exception. This will work similar to JDK {{CompletableFuture}}.

This message was sent by Atlassian JIRA

View raw message