[
https://issues.apache.org/jira/browse/HBASE-20802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16526998#comment-16526998
]
Duo Zhang commented on HBASE-20802:
-----------------------------------
{quote}
Indeed, interrupt won't always work.
{quote}
I think the only way to implement this is to set a flag and then try to
interrupt it. And when it comes back, it checks the flag first and decides
whether to call the remoteCallFailed method. No big advantage comparing to
adding a check in the remoteCallFailed method itself? And if we really want to
interrupt the call, just interrupt it inside remoteCallFailed?
> 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)
