[
https://issues.apache.org/jira/browse/HBASE-16285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15395568#comment-15395568
]
Anoop Sam John commented on HBASE-16285:
----------------------------------------
System.currentTimeMillis()
Better use EnvironmentEdgeManager?
dropTimeoutRequestDelay
We need this? Can u explain? The timestamp of call is the time it arrived
server and timeout says the client time out value. Why still this small delta?
So within the timeout period the server has not processed it but in small delta
gap it can be processed and reponded and client sees that? That is very rare
no? Just inform client that it is unsuccessful op to server? Even if client
was not really timed out and then see as fail. That is ok? We can avoid
overhead of one more config!
> Drop RPC requests if it must be considered as timeout at client
> ---------------------------------------------------------------
>
> Key: HBASE-16285
> URL: https://issues.apache.org/jira/browse/HBASE-16285
> Project: HBase
> Issue Type: Improvement
> Reporter: Phil Yang
> Assignee: Phil Yang
> Attachments: HBASE-16285-branch-1-v1.patch, HBASE-16285-v1.patch
>
>
> After HBASE-15593, we have a timeout param in header of RPC requests. We can
> use it in more scenes.
> A straightforward scene is to drop requests if it has waited so long in RPC
> queue and has been dropped by client. Even if we handle this request and send
> the response back, it will not be used any more. And client may have sent a
> retry. In an extreme case, if the server is slow, all requests may be timeout
> or queue-full-exception because we should handle previous requests which have
> been dropped by client and many resources at server are wasted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
