[
https://issues.apache.org/jira/browse/HBASE-20802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16526989#comment-16526989
]
stack commented on HBASE-20802:
-------------------------------
bq. .... and we also need to take care of the timing on when to interrupt the
call during the server crash processing
This is done already (we call cleanup AFTER log replay) I believe.
bq. Add a guard in the remoteCallFailed implementation itself will be more
suitable here I think.
Yeah, thats the parent issue.
bq. I think it is a bit hard to implement as we use sync rpc calls
What you thinking?
Indeed, interrupt won't always work. Then we defer to the timeout. Would be
good to make work though rather than having stuck RPCs hanging out.
> Add an interruptCall to RemoteProcedureDispatch
> -----------------------------------------------
>
> Key: HBASE-20802
> URL: https://issues.apache.org/jira/browse/HBASE-20802
> Project: HBase
> Issue Type: Sub-task
> Components: amv2
> Reporter: stack
> Priority: Major
>
> Follow-on from the parent. In summary, RPC's to zombie servers can get
> stuck/hang. We'll notice the server has gone non-responsive after a while and
> will effect repair but the RPCs will remain up until they go to their timeout
> (default 3minutes).
> This issue is about adding a means of interrupting an ongoing RPC.
> ServerCrashProcedure does cleanup of any ongoing, unsatisfied
> assigns/unassigns. As part of this cleanup, it could interrupt any
> outstanding RPCs.
> We'd add an interruptCall to the below interface in RemoteProcedureDispatch
> {code}
> public interface RemoteProcedure<TEnv, TRemote> {
> RemoteOperation remoteCallBuild(TEnv env, TRemote remote);
> void remoteCallCompleted(TEnv env, TRemote remote, RemoteOperation
> response);
> void remoteCallFailed(TEnv env, TRemote remote, IOException exception);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
