[
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)
