[
https://issues.apache.org/jira/browse/HBASE-16063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15338869#comment-15338869
]
Hiroshi Ikeda commented on HBASE-16063:
---------------------------------------
bq. I do not see how we could lock up. If the unlikely event of all handlers
doing step #3 in the above before #4 happened, the next request would free us
up again....
Yes, I just think the trapped request is delayed until the next request is
coming. That would be realized in some rare cases in low load, rather than in
heavy congestion. That seems trivial, though there seems no easy way to fix.
> Race condition in new FIFO fastpath from HBASE-16023
> ----------------------------------------------------
>
> Key: HBASE-16063
> URL: https://issues.apache.org/jira/browse/HBASE-16063
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 1.3.0
> Reporter: stack
>
> From [~ikeda] over in HBASE-16023 at
> https://issues.apache.org/jira/browse/HBASE-16023?focusedCommentId=15331172&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15331172
> {quote}
> An concrete example of the race condition:
> 1. Worker checks no task.
> 2. Reader checks no ready handler.
> 3. Worker pushes itself as a ready handler and waits on the semaphore.
> 4. Reader queues a task to the queue, without directly passing it to the
> ready handler nor releasing the semaphore.
> (1,3) and (2,4) should be exclusively executed. That depends on luck, and it
> might be not severe
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
