You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ariatosca.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2017/05/07 09:28:04 UTC
[jira] [Commented] (ARIA-143) Cancelling of workflow execution
[ 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)