[jira] [Commented] (HBASE-10605) Manage the call timeout in the server
[ https://issues.apache.org/jira/browse/HBASE-10605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15183013#comment-15183013 ] Nicolas Liochon commented on HBASE-10605: - > , I think client rpc should include the timeout parameter Yes, we would need to forward the timeout (not the the submit time, because we don't want to rely on having the server and client clocks in sync: the server can use its own clock). Then there is already a check in the server, the request is cancelled if the client is disconnected (i.e. the tcp connection is closed). > Manage the call timeout in the server > - > > Key: HBASE-10605 > URL: https://issues.apache.org/jira/browse/HBASE-10605 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC, regionserver >Affects Versions: 0.99.0 >Reporter: Nicolas Liochon > > Since HBASE-10566, we have an explicit call timeout available in the client. > We could forward it to the server, and use this information for: > - if the call is still in the queue, just cancel it > - if the call is under execution, makes this information available in > RpcCallContext (actually change the RpcCallContext#disconnectSince to > something more generic), so it can be used by the query under execution to > stop its execution > - in the future, interrupt it to manage the case 'stuck on a dead datanode' > or something similar > - if the operation has finished, don't send the reply to the client, as by > definition the client is not interested anymore. > From this, it will be easy to manage the cancellation: > disconnect/timeout/cancellation are similar from a service execution PoV -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-10605) Manage the call timeout in the server
[ https://issues.apache.org/jira/browse/HBASE-10605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159134#comment-15159134 ] Yong Zhang commented on HBASE-10605: How server side know client call timeout, I think client rpc should include the timeout parameter and submit time, and server side will have a monitor. And more hbase rpc client has retry, request time out seems after some calls failed or socket timeout, how to handle this scenario? > Manage the call timeout in the server > - > > Key: HBASE-10605 > URL: https://issues.apache.org/jira/browse/HBASE-10605 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC, regionserver >Affects Versions: 0.99.0 >Reporter: Nicolas Liochon > > Since HBASE-10566, we have an explicit call timeout available in the client. > We could forward it to the server, and use this information for: > - if the call is still in the queue, just cancel it > - if the call is under execution, makes this information available in > RpcCallContext (actually change the RpcCallContext#disconnectSince to > something more generic), so it can be used by the query under execution to > stop its execution > - in the future, interrupt it to manage the case 'stuck on a dead datanode' > or something similar > - if the operation has finished, don't send the reply to the client, as by > definition the client is not interested anymore. > From this, it will be easy to manage the cancellation: > disconnect/timeout/cancellation are similar from a service execution PoV -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-10605) Manage the call timeout in the server
[ https://issues.apache.org/jira/browse/HBASE-10605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105088#comment-15105088 ] Nicolas Liochon commented on HBASE-10605: - Hi [~java8964], what do you need to know? The point of this jira if that the server should not continue to handle a request if we know that the client has already stopped waiting for the result. > Manage the call timeout in the server > - > > Key: HBASE-10605 > URL: https://issues.apache.org/jira/browse/HBASE-10605 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC, regionserver >Affects Versions: 0.99.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > > Since HBASE-10566, we have an explicit call timeout available in the client. > We could forward it to the server, and use this information for: > - if the call is still in the queue, just cancel it > - if the call is under execution, makes this information available in > RpcCallContext (actually change the RpcCallContext#disconnectSince to > something more generic), so it can be used by the query under execution to > stop its execution > - in the future, interrupt it to manage the case 'stuck on a dead datanode' > or something similar > - if the operation has finished, don't send the reply to the client, as by > definition the client is not interested anymore. > From this, it will be easy to manage the cancellation: > disconnect/timeout/cancellation are similar from a service execution PoV -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-10605) Manage the call timeout in the server
[ https://issues.apache.org/jira/browse/HBASE-10605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15085102#comment-15085102 ] Yong Zhang commented on HBASE-10605: Hi [~nkeywal], can please you give more info for handle client retrying and server timeout behavior? > Manage the call timeout in the server > - > > Key: HBASE-10605 > URL: https://issues.apache.org/jira/browse/HBASE-10605 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC, regionserver >Affects Versions: 0.99.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > > Since HBASE-10566, we have an explicit call timeout available in the client. > We could forward it to the server, and use this information for: > - if the call is still in the queue, just cancel it > - if the call is under execution, makes this information available in > RpcCallContext (actually change the RpcCallContext#disconnectSince to > something more generic), so it can be used by the query under execution to > stop its execution > - in the future, interrupt it to manage the case 'stuck on a dead datanode' > or something similar > - if the operation has finished, don't send the reply to the client, as by > definition the client is not interested anymore. > From this, it will be easy to manage the cancellation: > disconnect/timeout/cancellation are similar from a service execution PoV -- This message was sent by Atlassian JIRA (v6.3.4#6332)
