hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiroshi Ikeda (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-16063) Race condition in new FIFO fastpath from HBASE-16023
Date Mon, 20 Jun 2016 01:30:05 GMT

    [ 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

View raw message