[
https://issues.apache.org/jira/browse/MESOS-9748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16829024#comment-16829024
]
Benjamin Bannier commented on MESOS-9748:
-----------------------------------------
[~chhsia0], one could also argue that a framework which let's offers time out
instead of accepting or declining them has already violated the offer protocol.
I agree that implicit behavior can be confusing, but I believe one could argue
here from a position of Mesos guarding itself against misbehaving frameworks
(especially important since we rely on frameworks behaving correctly).
> Consider installing filters if offers time out
> ----------------------------------------------
>
> Key: MESOS-9748
> URL: https://issues.apache.org/jira/browse/MESOS-9748
> Project: Mesos
> Issue Type: Improvement
> Components: allocation, master
> Reporter: Benjamin Bannier
> Priority: Major
>
> We currently do not install any filters if an offer to a framework times out.
> We should consider recovering with a filter for some duration.
> This can be interesting in cases where e.g., framework offer processing is
> backlogged so it cannot accept offers in time. If no filter is installed we
> could end up allocating to that framework again and again (and exclusively if
> other frameworks already use more resources than what we offer the backlogged
> framework at a time).
> If we would instead filter the resources from timed out offers for some
> allocation cycle, we could extert some form of backpressure on the
> framework's behalf which could allow it to recover. We also would give a
> chance that other frameworks can actually use the resources.
> The optimal duration to filter the resources for would depend on the
> (dynamic) number of frameworks interested in offers and might be hard to
> determine. Filtering for a single allocation cycle might be a good starting
> point to get some of the benefits without causing too much new behavior.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
