[
https://issues.apache.org/jira/browse/ARIA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15999748#comment-15999748
]
ASF GitHub Bot commented on ARIA-143:
-------------------------------------
GitHub user AviaE opened a pull request:
https://github.com/apache/incubator-ariatosca/pull/121
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.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/incubator-ariatosca
ARIA-143-better-handle-exceptions-in-the-process-executor
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-ariatosca/pull/121.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #121
----
commit e5c6522cfefffe699ab742c790d102ebce227090
Author: Avia Efrat <[email protected]>
Date: 2017-05-07T08:42:58Z
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)
