[
https://issues.apache.org/jira/browse/HBASE-20000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16366671#comment-16366671
]
Appy commented on HBASE-20000:
------------------------------
bq. Unfortunately this is a bug fix...
If this is fixing bugs, that's fortunate! :)
I missed to see that it was a sub-task, so without context i thought it was
general refactor. Sorry.
bq. When implementing HBASE-19397 I found that this is not trivial... Usually
the parent procedure will release the lock after switching out so anyone can
acquire the lock again... We have a holdLock method for Procedure which can
control whether to always hold the lock even if you are not running at the
time...
Yups, the whole framework is!
Parent procedure giving away the lock is covered by that invariant no? ....it's
child procedure *may* get blocked. ("will" if some other proc acquire it, 'will
not' if the child proc itself acquire it. (But we can always reword it better,
it was just first cut suggestion).
To me, holdlock seemed to be just optimization, give away the lock if you
(proc) are yielding and don't need exclusion - just good samaritan way? Not
sure though if any proc is actually doing that or all just keep the lock held.
Or maybe it's not worth the complexity in framework. Yeah let's see after 2.0.
Given that quantum logic is gone, it does't look "fair" anymore, should be
renamed to "PriorityQueue" in future?
> Remove the quantum logic in FairQueue, always put high priority queue in front
> ------------------------------------------------------------------------------
>
> Key: HBASE-20000
> URL: https://issues.apache.org/jira/browse/HBASE-20000
> Project: HBase
> Issue Type: Sub-task
> Components: proc-v2
> Reporter: Duo Zhang
> Assignee: Duo Zhang
> Priority: Major
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-20000-branch-2.patch, HBASE-20000-v1.patch,
> HBASE-20000.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
