You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Meng Zhu (JIRA)" <ji...@apache.org> on 2019/05/16 12:50:00 UTC

[jira] [Assigned] (MESOS-9786) Race between two REMOVE_QUOTA calls crashes the master.

     [ https://issues.apache.org/jira/browse/MESOS-9786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Meng Zhu reassigned MESOS-9786:
-------------------------------

    Assignee: Meng Zhu

> Race between two REMOVE_QUOTA calls crashes the master.
> -------------------------------------------------------
>
>                 Key: MESOS-9786
>                 URL: https://issues.apache.org/jira/browse/MESOS-9786
>             Project: Mesos
>          Issue Type: Bug
>    Affects Versions: 1.5.1, 1.8.0, 1.8.1
>            Reporter: Andrei Sekretenko
>            Assignee: Meng Zhu
>            Priority: Major
>              Labels: resource-management
>
> The existence of the quota in the master is validated here:
> [https://github.com/apache/mesos/blob/a9a2acabd03181865055b77cf81e7bb310b236d6/src/master/quota_handler.cpp#L700]
> Then the quota is removed from master in a deferred method call:
> [https://github.com/apache/mesos/blob/a9a2acabd03181865055b77cf81e7bb310b236d6/src/master/quota_handler.cpp#L744]
> And then removed from allocator in another deferred call:
> [https://github.com/apache/mesos/blob/a9a2acabd03181865055b77cf81e7bb310b236d6/src/master/quota_handler.cpp#L753]
> So, there is a race between two simultaneous REMOVE_QUOTA calls.
> We observe this race on a heavily loaded cluster. Currently we suspect that the client retries the call (due to the call being not processed for a long time),  and this triggers the race.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)