[
https://issues.apache.org/jira/browse/HADOOP-16268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841573#comment-16841573
]
Erik Krogen commented on HADOOP-16268:
--------------------------------------
Hey [~crh], the idea seems good. A few comments:
* You've currently made the change within {{CallQueueManager#throwBackoff()}},
but this logic is only used when {{shouldBackOff()}} is true, so it is only
triggered from the response time based back-off. You'll also need to take a
look at {{FairCallQueue#add()}}, which triggers backoff based off of the queue
being full. Ideally we should probably unify this logic.
* I think it would be better if the config was scoped to a certain IPC
namespace, similar to the other IPC configs, so that you can specify it only
for certain IPC servers. For example the configs today are like
{{ipc.8020.callqueue.impl}} so that you can change the impl for only the client
RPC server.
* I wonder if it would be possible to make this config a bit more general, by
allowing the user to specify a class to throw on backoff, or specify one of
{{DISCONNECT}} / {{FAILOVER}} / {{KEEPALIVE}}? Just a thought.
> 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
> 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.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
