From: Andrew Deason Date: Thu, 30 Jan 2014 06:02:24 +0000 (-0600) Subject: rx: Set lastBusy on RX_CALL_TIMEOUT X-Git-Tag: upstream/1.8.0_pre1^2~358 X-Git-Url: https://git.michaelhowe.org/gitweb/?a=commitdiff_plain;h=d309b193671a85c118e75c82171144c52ad1c48c;p=packages%2Fo%2Fopenafs.git 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 --- 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);