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

Benjamin Mahler commented on MESOS-1456:
----------------------------------------

To generalize a bit, there are some current semantics on dispatches that are of 
interest here:

(1) If a dispatch occurs for an invalid PID, then the future remains pending.
(2) If a dispatch is enqueued behind a terminate event, then the future remains 
pending.

I'm curious if it makes sense to return discarded futures in these two cases. 
One thing to consider is that in general we avoid the pattern of the callee 
returning a discarded future without the caller asking for a discard. In this 
case however, it seems acceptable to be discarding because the callee is 
_forced_ to discard the operation (the dispatch event cannot be executed now or 
ever, and must be dropped / thrown away).

It's possible to modify DispatchEvent to take an optional shared pointer to the 
underlying Promise, if the dispatch has one associated with it. This allows the 
DispatchEvent to discard the promise upon destruction. Curious to see how make 
check will respond to this change.

> Metric lifetime should be tied to process runstate, not lifetime.
> -----------------------------------------------------------------
>
>                 Key: MESOS-1456
>                 URL: https://issues.apache.org/jira/browse/MESOS-1456
>             Project: Mesos
>          Issue Type: Bug
>          Components: statistics
>    Affects Versions: 0.19.0
>            Reporter: Dominic Hamon
>            Assignee: Dominic Hamon
>
> The usual pattern for termination of processes is {{terminate(..); wait(..); 
> delete ..;}} but the {{SchedulerProcess}} is terminated and then deleted some 
> time later.
> If the metrics endpoint is accessed within that period, it never returns as 
> it tries to access a {{Gauge}} that has a reference to a valid PID that is 
> not getting any timeslices (the {{SchedulerProcess}}). A one-off fix can be 
> made to the {{SchedulerProcess}} to move the metrics add/remove calls to 
> {{initialize}} and {{finalize}}, but this should be the general pattern for 
> every process with metrics. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to