mesos-issues mailing list archives

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


Yan Xu commented on MESOS-5280:

Derived from the discussion [here|]:

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
- The sorter should never assume the allocator would call its methods in the expected way/order.
 (e.g., [here|]
the method has no safegards at all).

/cc [~jvanremoortere]

> Inconsistent error checking in DRF sorter.
> ------------------------------------------
>                 Key: MESOS-5280
>                 URL:
>             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|]
> {code}
> CHECK(weights.contains(name));
> {code}
> h2. No-op if it results in an error condition.
> e.g., [DRFSorter::allocated|]:
> {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

View raw message