[jira] [Commented] (MESOS-2657) Support multiple reasons in status update message.
[ https://issues.apache.org/jira/browse/MESOS-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214182#comment-16214182 ] Zongfang Lin commented on MESOS-2657: - I try the Java framework in examples, and get the same error. ``` Received offer 56345a6a-90fe-4d03-b864-fb7d3cd0fee9-O0 with cpus: 4.0 and mem: 6380.0 Launching task 0 using offer 56345a6a-90fe-4d03-b864-fb7d3cd0fee9-O0 Launching task 1 using offer 56345a6a-90fe-4d03-b864-fb7d3cd0fee9-O0 Launching task 2 using offer 56345a6a-90fe-4d03-b864-fb7d3cd0fee9-O0 Launching task 3 using offer 56345a6a-90fe-4d03-b864-fb7d3cd0fee9-O0 Status update: task 0 is in state TASK_FAILED Aborting because task 0 is in unexpected state TASK_FAILED with reason 'REASON_EXECUTOR_TERMINATED' from source 'SOURCE_SLAVE' with message 'Executor terminated' ``` > Support multiple reasons in status update message. > -- > > Key: MESOS-2657 > URL: https://issues.apache.org/jira/browse/MESOS-2657 > Project: Mesos > Issue Type: Improvement >Reporter: Jie Yu >Assignee: haosdent > > Sometimes, a single reason in the status update message makes it very hard > for frameworks to understand the cause of a status update. For example, we > have REASON_EXECUTOR_TERMINATED, but that's a very general reason and > sometime we want a sub-reason for that (e.g., REASON_CONTAINER_LAUNCH_FAILED) > so that the framework can better react to the status update. > We could change 'reason' field in TaskStatus to be a repeated field (should > be backward compatible). For instance, for a containerizer launch failure, we > probably need two reasons for TASK_LOST: 1) the top level reason > REASON_EXECUTOR_TERMINATED; 2) the second level reason > REASON_CONTAINER_LAUNCH_FAILED. > Another example. We may want to have a generic reason when resource limit is > reached: REASON_RESOURCE_LIMIT_EXCEEDED, and have a second level sub-reason: > REASON_OUT_OF_MEMORY. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-2657) Support multiple reasons in status update message.
[
https://issues.apache.org/jira/browse/MESOS-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175579#comment-16175579
]
James Peach commented on MESOS-2657:
[~haosd...@gmail.com] [~jieyu] As part of the refactoring for MESOS-7963, I'm
planning to remove the multiple reasons in the {{ContainerTermination}}
message. I think the main use case for that was supporting multiple limitations
from isolators, but that never worked and I'm removing that as well :)
Please let me know if you see any problems with this.
> Support multiple reasons in status update message.
> --
>
> Key: MESOS-2657
> URL: https://issues.apache.org/jira/browse/MESOS-2657
> Project: Mesos
> Issue Type: Improvement
>Reporter: Jie Yu
>Assignee: haosdent
>
> Sometimes, a single reason in the status update message makes it very hard
> for frameworks to understand the cause of a status update. For example, we
> have REASON_EXECUTOR_TERMINATED, but that's a very general reason and
> sometime we want a sub-reason for that (e.g., REASON_CONTAINER_LAUNCH_FAILED)
> so that the framework can better react to the status update.
> We could change 'reason' field in TaskStatus to be a repeated field (should
> be backward compatible). For instance, for a containerizer launch failure, we
> probably need two reasons for TASK_LOST: 1) the top level reason
> REASON_EXECUTOR_TERMINATED; 2) the second level reason
> REASON_CONTAINER_LAUNCH_FAILED.
> Another example. We may want to have a generic reason when resource limit is
> reached: REASON_RESOURCE_LIMIT_EXCEEDED, and have a second level sub-reason:
> REASON_OUT_OF_MEMORY.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
