[
https://issues.apache.org/jira/browse/MESOS-4302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15088596#comment-15088596
]
Klaus Ma commented on MESOS-4302:
---------------------------------
Regarding {{reviveOffers}}, do you mean I have to call {{reviveOffers}} just
after launching tasks? But how do I distinguish special filter and re-shuffle
filter?
This case is about re-shuffling resources between "nice/friendly"framework.
{{offerRescinded}} is a better solution for that; but it seems only Quota &
Maintenance will trigger it for now. I logged a JIRA (MESOS-4303) about
re-shuffling resources between framework. I think it's too early to do this
ticket before framework support it when re-shuffling.
> Offer filter timeouts are ignored if the allocator is slow or backlogged.
> -------------------------------------------------------------------------
>
> Key: MESOS-4302
> URL: https://issues.apache.org/jira/browse/MESOS-4302
> Project: Mesos
> Issue Type: Bug
> Components: allocation
> Reporter: Benjamin Mahler
> Assignee: Alexander Rukletsov
> Priority: Critical
> Labels: mesosphere
>
> Currently, when the allocator recovers resources from an offer, it creates a
> filter timeout based on time at which the call is processed.
> This means that if it takes longer than the filter duration for the allocator
> to perform an allocation for the relevant agent, then the filter is never
> applied.
> This leads to pathological behavior: if the framework sets a filter duration
> that is smaller than the wall clock time it takes for us to perform the next
> allocation, then the filters will have no effect. This can mean that low
> share frameworks may continue receiving offers that they have no intent to
> use, without other frameworks ever receiving these offers.
> The workaround for this is for frameworks to set high filter durations, and
> possibly reviving offers when they need more resources, however, we should
> fix this issue in the allocator. (i.e. derive the timeout deadlines and
> expiry based on allocation times).
> This seems to warrant cherry-picking into bug fix releases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)