mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yan Xu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MESOS-5280) Inconsistent error checking in DRF sorter.
Date Wed, 08 Jun 2016 17:23:21 GMT

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

Yan Xu commented on MESOS-5280:
-------------------------------

Derived from the discussion [here|https://reviews.apache.org/r/47259/]:

IMO we should:
- CHECK internal invariants.
- Return error/none/false for invalid arguments or no-ops. If some of these things should
never happen, they should be CHECKs in the caller (the allocator) because they are its internal
invariants.
- The sorter should never assume the allocator would call its methods in the expected way/order.
 (e.g., [here|https://github.com/apache/mesos/blob/6ce476461f0fedfb4ed4e40c15f25bb79a39b0f3/src/master/allocator/sorter/drf/sorter.cpp#L242]
the method has no safegards at all).

/cc [~jvanremoortere]

> Inconsistent error checking in DRF sorter.
> ------------------------------------------
>
>                 Key: MESOS-5280
>                 URL: https://issues.apache.org/jira/browse/MESOS-5280
>             Project: Mesos
>          Issue Type: Bug
>          Components: allocation
>            Reporter: Yan Xu
>            Assignee: Yan Xu
>
> There exist a few different error handling styles in the sorter.
> h2. Hard checks
> e.g., [DRFSorter::update|https://github.com/apache/mesos/blob/c530deb3050d862fd894a9c4ed0a8ddca8714a63/src/master/allocator/sorter/drf/sorter.cpp#L62]
> {code}
> CHECK(weights.contains(name));
> {code}
> h2. No-op if it results in an error condition.
> e.g., [DRFSorter::allocated|https://github.com/apache/mesos/blob/c530deb3050d862fd894a9c4ed0a8ddca8714a63/src/master/allocator/sorter/drf/sorter.cpp#L116]:
> {code}
> set<Client, DRFComparator>::iterator it = find(name);
> if (it != clients.end()) { // TODO(benh): This should really be a CHECK.
> ...
> }
> {code}
> IMO there should never be silent no-ops. Short of CHECK, we should return an error if
it's indeed an error. If either path of the branch is valid and one is a  noop, we should
log the noop branch or return a 'bool' so the caller can distinguish the two.
> Implicitness makes it hard to debug things and we have run into one instance of this.
> My proposal is to use CHECKs consistently in sorter.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message