ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARIA-143) Cancelling of workflow execution
Date Sun, 07 May 2017 09:28:04 GMT

    [ https://issues.apache.org/jira/browse/ARIA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15999747#comment-15999747
] 

ASF subversion and git services commented on ARIA-143:
------------------------------------------------------

Commit e5c6522cfefffe699ab742c790d102ebce227090 in incubator-ariatosca's branch refs/heads/ARIA-143-better-handle-exceptions-in-the-process-executor
from [~avia]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-ariatosca.git;h=e5c6522 ]

ARIA-143 Better handle exceptions in the process executor

Previously, if an exception was raised during the starting of a task,
the task's process was permenantly blocked on receiving a message.

The reason was that the execption caused the 'listener thread' to
not send a response the to the task's process, as the exception was not handled inside the
'with' block of the listener thread.

The first change I introduced was to wrap the yielding of the message and
the response inside a try-except-finally block, so the exception will be
handled within the 'with' scope, and to ensure a response is sent to the
task's process.

The second change is to move the sending of the 'task started' message in
the task's process to a place where encountering an exception will be
handled via sending a 'task failed' message back to the listener thread.


> Cancelling of workflow execution
> --------------------------------
>
>                 Key: ARIA-143
>                 URL: https://issues.apache.org/jira/browse/ARIA-143
>             Project: AriaTosca
>          Issue Type: Story
>    Affects Versions: 0.1.0
>            Reporter: Avia Efrat
>            Assignee: Avia Efrat
>             Fix For: 0.1.0
>
>
> Make the process of cancelling execution more robust:
> - Identify possible pitfalls and corner cases.
> - Implement force cancelling.
> **************
> *Conclusions:*
> Unhandled execution status transitions resulting from cancelling an
> execution via the CLI, that we indentified and tried to address:
>     TERMINATED -> CANCELLING
>     You cancel the execution, but by the time we try to set the status to
>     CANCELLING, the execution thread had already finished, and therefore, in
>     SUCCEEDED status.
>     FAILED -> CANCELLING
>     You cancel the execution, but by the time we try to set the status to
>     CANCELLING, the execution thread had already encountered an error, and therefore,
in
>     FAILED state.
>     TERMINATED -> CANCELLED
>     Similar to #1, but with CANCELLED instead of CANCELLING.
>     FAILED -> CANCELLED
>     Similar to #1, but with CANCELLED instead of CANCELLING.
> In all of the above cases (#1-#4), we skip updating the execution status,
> and log that the execution already succeeded/failed before we were able
> to cancel it.
>     CANCELLING -> STARTED
>     You cancel the execution while it is still in pending state. Meanwhile,
>     while the execution status was already set to CANCELLING, we try to set
>     the execution status
>     CANCELLED -> STARTED
>     Similar to #5, but after the status is set to CANCELLING, it also gets
>     set to CANCELLED before attempting to set it to STARTED.
> In cases #5-#6, we skip updtating the execution status, and nothing is logged.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message