hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy Xiang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-11565) Stale connection could stay for a while
Date Tue, 22 Jul 2014 22:38:40 GMT

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

Jimmy Xiang commented on HBASE-11565:
-------------------------------------

bq. The synchronized (this) is safe? There is no risk to create a deadlock somehow?
It is safe, no deadlock concern. Originally, it calls markClosed(e) directly, which synchronizes
on this too. So there is no change here as to synchronized/deadlock here.

bq. Why do you think that interrupting the reader thread twice is bad? We would leak some
resources?
When the reader thread is interrupted for the first time, it could get out the readResponse()
call and move to close() call. So it could be calling IOUtils.closeStream. My concern is such
a call can throw an InterruptedException and the remain part of the close() call is not executed.
The synchrononized here is to make things safer.


> Stale connection could stay for a while
> ---------------------------------------
>
>                 Key: HBASE-11565
>                 URL: https://issues.apache.org/jira/browse/HBASE-11565
>             Project: HBase
>          Issue Type: Bug
>          Components: Client
>            Reporter: Jimmy Xiang
>            Assignee: Jimmy Xiang
>         Attachments: hbase-11565-0.98.patch, hbase-11565-v1.patch
>
>
> In RpcClient, we cache the connection to each region server. When the connection goes
bad, it stays in the cache till it's removed. Before it's removed, new calls will try to use
it and just fail. The connection is a thread. It could be stuck in trying to receive some
response. Before this receiving thread times out, it won't remove itself from the cache.
> It will be better to interrupt the receiving thread and let it clean up sooner.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message