You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Jean-Daniel Cryans (JIRA)" <ji...@apache.org> on 2017/08/25 21:46:00 UTC

[jira] [Updated] (KUDU-790) Not all MM ops acquire locks in Prepare()

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

Jean-Daniel Cryans updated KUDU-790:
------------------------------------
    Target Version/s: Backlog  (was: 1.5.0)

> Not all MM ops acquire locks in Prepare()
> -----------------------------------------
>
>                 Key: KUDU-790
>                 URL: https://issues.apache.org/jira/browse/KUDU-790
>             Project: Kudu
>          Issue Type: Bug
>          Components: tablet
>    Affects Versions: M5
>            Reporter: Adar Dembo
>
> The maintenance manager invokes Prepare() on its scheduler thread and thunks Perform() to a separate thread pool. If an op doesn't lock the rowsets it's going to modify in Prepare(), there's a chance that the MM scheduler thread may run again before Perform() is invoked (i.e. before those locks are acquired. If this happens, the scheduler thread may compute the same stats and schedules the same op.
> All of the ops are safe to call concurrently (well, those that aren't use external synchronization to ensure that this doesn't happen), but what happens next depends on the specific op and the timing. The second op may no-op, or it may perform less useful work and waste time.
> Ideally Prepare() should acquire any and all locks needed by Perform(), so that if the scheduler thread runs again, it'll compute different stats (since those usually depend on acquiring rowset locks) and either not schedule the op, or schedule a different body of work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)