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

CR Hota commented on HADOOP-16268:
----------------------------------

[~xkrogen] Thanks for the review. Below is a little explanation of the change.

The idea here is to back off even if {{FairCallQueue}} is not configured 
(FairCallQueue in the context of router doesn't help much, as fairness in 
routers has a separate context as mentioned in HDFS-14090). So irrespective of 
actual queue implementation, if a queue is full call manager should throw 
{{StandbyException}} instead {{RetriableException}}. In case {{FairCallQueue}} 
is not enabled, the default {{LinkedBlockingQueue}} is used, which will throw 
an {{IllegalStateException}} when full and this exception also gets handled by 
{{throwBackoff}} logic. Let me know your thoughts.

[~jojochuang] [~elgoiri] [~brahmareddy] FYI ..

> Allow custom wrapped exception to be thrown by server if RPC call queue is 
> filled up
> ------------------------------------------------------------------------------------
>
>                 Key: HADOOP-16268
>                 URL: https://issues.apache.org/jira/browse/HADOOP-16268
>             Project: Hadoop Common
>          Issue Type: Improvement
>            Reporter: CR Hota
>            Assignee: CR Hota
>            Priority: Major
>         Attachments: HADOOP-16268.001.patch
>
>
> In the current implementation of callqueue manager, 
> "CallQueueOverflowException" exceptions are always wrapping 
> "RetriableException". Through configs servers should be allowed to throw 
> custom exceptions based on new use cases.
> In CallQueueManager.java for backoff the below is done 
> {code:java}
>   // ideally this behavior should be controllable too.
>   private void throwBackoff() throws IllegalStateException {
>     throw CallQueueOverflowException.DISCONNECT;
>   }
> {code}
> Since CallQueueOverflowException only wraps RetriableException clients would 
> end up hitting the same server for retries. In use cases that router supports 
> these overflowed requests could be handled by another router that shares the 
> same state thus distributing load across a cluster of routers better. In the 
> absence of any custom exception, current behavior should be supported.
> In CallQueueOverflowException class a new Standby exception wrap should be 
> created. Something like the below
> {code:java}
>    static final CallQueueOverflowException KEEPALIVE =
>         new CallQueueOverflowException(
>             new RetriableException(TOO_BUSY),
>             RpcStatusProto.ERROR);
>     static final CallQueueOverflowException DISCONNECT =
>         new CallQueueOverflowException(
>             new RetriableException(TOO_BUSY + " - disconnecting"),
>             RpcStatusProto.FATAL);
>     static final CallQueueOverflowException DISCONNECT2 =
>         new CallQueueOverflowException(
>             new StandbyException(TOO_BUSY + " - disconnecting"),
>             RpcStatusProto.FATAL);
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to