mesos-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Bordelon <>
Subject Re: Is DRF unreasonable in scenarios with multiple frameworks registered at the same time?
Date Thu, 09 Apr 2015 18:43:32 GMT
If Chronos is in fact further below its fair share at any given point in
time, then it will always get the offer. If, however, Chronos recently
declined that offer and we're still within its refuse_interval, then it
will have to be offered to the next framework (Marathon). In the scenario
where Chronos drastically reduces its refuse_interval (to 0.1s), it was
never giving other frameworks the opportunity to be offered those
resources. Since the default mesos allocation interval is 1s, that pretty
much guarantees that Chronos' 0.1s refuse_interval had already expired by
the time the next allocation round occurs, so it gets offered the same
resources again.
The refuse_interval should never be less than the master's
allocation_interval. This has been fixed in the latest Chronos.

On Thu, Apr 9, 2015 at 10:59 AM, Elizabeth Lingg <>

> Hello,
> Changing the offer refuse interval to the default was done in Chronos
> master. We are pushing out another Chronos release with some important
> changes including that one soon.
> However, the question still remains, why does Chronos keep getting the
> offer back after refusal and why is it not offered to Marathon? Even with a
> different refuse interval, I would think that with the fair share
> algorithm, Marathon would also get the offer as well. Could you possibly
> comment on this JIRA issue as well,
>, so we can investigate?
> Thanks,
> Elizabeth
> On Wed, Apr 8, 2015 at 9:44 PM, <> wrote:
>> @Elizabeth, we did encountered the same issue.
>> I just verified that both mesos-0.20.1 and the latest mesos-0.22.0 work
>> OK if I comment chronos refuse filter, that makes the refuse second changed
>> back to default 5s, if not, both mesos versions fail.
>> 2015年4月9日 上午8:48于 sujz.buaa@qq.com写道:
>> @David, after receiving and declining offer for the first time, chronos's
>> share is still the smaller one, so mesos continues to provide offer to
>> chronos instead of marathon.
>> @Elizabeth, I will try with the latest mesos a moment later.
>> 2015年4月9日 上午8:37于 Elizabeth Lingg <>写道:
>> Correct, the issue we were seeing is that Chronos would decline the
>> offer, but Chronos would keep getting it back instead of it being offered
>> to Marathon. We were reproducing this issue on a cluster with a single
>> master/slave, which is a bit of an anti-pattern. I'm not sure if anyone was
>> able to reproduce this with the latest version of Mesos.
>> -Elizabeth
>> On Wed, Apr 8, 2015 at 5:19 PM, David Greenberg <>
>> wrote:
>>> I believe that DRF is more of a "right of first refusal." Even though
>>> marathon's got the higher share, all that means is that chronos will get
>>> the offer first; marathon will have to wait until chronos declines it.
>>> On Wed, Apr 8, 2015 at 5:33 PM Elizabeth Lingg <>
>>> wrote:
>>>> Hi,
>>>> This sounds like an issue we encountered,
>>>> Are you able to
>>>> reproduce this in the latest release? If so, could you add a comment to the
>>>> issue?
>>>> Thanks,
>>>> Elizabeth
>>>> On Wed, Apr 8, 2015 at 3:35 AM, <> wrote:
>>>>> Suppose I registered two frameworks namely marathon and chronos(both
>>>>> in role *) one after another, successfully deployed  and run one app
>>>>> by marathon, also deployed one cron app app2 by chronos, before app2
due or
>>>>> after app2 finished, I can't deploy and launch any new app by marathon
>>>>> although there are many resources left, because mesos will send offer
>>>>> chronos all the time as share of chronos is smaller according to DRF,
so is
>>>>> DRF unreasonable and is there any advice on how to allocate resources
>>>>> this scenario?  Any suggestipn will be appreciate.
>>>>> Best regards!

View raw message