From d309b193671a85c118e75c82171144c52ad1c48c Mon Sep 17 00:00:00 2001 From: Andrew Deason Date: Thu, 30 Jan 2014 00:02:24 -0600 Subject: [PATCH] rx: Set lastBusy on RX_CALL_TIMEOUT Currently, if a server RPC hangs forever, the client call will error out with RX_CALL_TIMEOUT (if idle/dead timeouts are configured). If we later try to make a new call on that conn, the server will respond with BUSY packets, and we'll have to wait until we RX_CALL_TIMEOUT again. After that we'll set lastBusy and avoid the call channel, but that extra delay with the BUSY packets is avoidable. So, avoid this extra delay by setting lastBusy when we kill a call with RX_CALL_TIMEOUT, so a future rx_NewCall will avoid the call channel. It makes sense to set lastBusy here, since the call channel is more likely to be busy than the other call channels. Change-Id: Iadf77f52ae418491e3108a4b0b5388361f2424aa Reviewed-on: http://gerrit.openafs.org/10785 Reviewed-by: Daria Brashear Reviewed-by: Benjamin Kaduk Tested-by: BuildBot Reviewed-by: Jeffrey Altman --- src/rx/rx.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/rx/rx.c b/src/rx/rx.c index 4bc1d4ed7..611ca1dd6 100644 --- a/src/rx/rx.c +++ b/src/rx/rx.c @@ -2418,6 +2418,11 @@ rx_EndCall(struct rx_call *call, afs_int32 rc) * The call channel is definitely not busy if we just successfully * completed a call on it. */ conn->lastBusy[call->channel] = 0; + + } else if (call->error == RX_CALL_TIMEOUT) { + /* The call is still probably running on the server side, so try to + * avoid this call channel in the future. */ + conn->lastBusy[call->channel] = clock_Sec(); } MUTEX_ENTER(&conn->conn_data_lock); -- 2.39.5