[ 
https://issues.apache.org/jira/browse/HBASE-10525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13907002#comment-13907002
 ] 

Nicolas Liochon commented on HBASE-10525:
-----------------------------------------

Thanks a lot for the detailed analysis, Enis. v4 fixes it and adds a test.

This scenario was ok already:
(connection marked as close)
reader close - cleanup expected reads
writer close - cleanup calls to writes
There is no possible race condition between the two, because we check the 
connection status in writeRequest. If you did the cleanup, it means that 
connectionClosed was true, so the writeRequest will fail.

another scenario was NOT ok:
new client get connection - connection is opened
(connection marked as closed)
reader close - cleanup expected reads
writer close - cleanup calls to writes
client thread add call to calls to write

The solution is to add a check after we add the call, exactly as in the first 
scenario. This does not require another synchronization point.


> Allow the client to use a different thread for writing to ease interrupt
> ------------------------------------------------------------------------
>
>                 Key: HBASE-10525
>                 URL: https://issues.apache.org/jira/browse/HBASE-10525
>             Project: HBase
>          Issue Type: Bug
>          Components: Client
>    Affects Versions: 0.99.0
>            Reporter: Nicolas Liochon
>            Assignee: Nicolas Liochon
>             Fix For: 0.99.0
>
>         Attachments: 10525.v1.patch, 10525.v2.patch, 10525.v3.patch, 
> 10525.v4.patch, HBaseclient-EventualConsistency.pdf
>
>
> This is an issue in the HBASE-10070 context, but as well more generally if 
> you want to interrupt an operation with a limited cost. 
> I will attach a doc with a more detailed explanation.
> This adds a thread per region server; so it's otional. The first patch 
> activates it by default to see how it behaves on a full hadoop-qa run. The 
> target is to be unset by default.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to