Re: [PATCH 6/9] sunrpc: close connection when a request is irretrievably lost.

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Feb 03, 2010 at 05:20:10PM -0500, Trond Myklebust wrote:
> On Thu, 2010-02-04 at 08:23 +1100, Neil Brown wrote: 
> > On Wed, 03 Feb 2010 10:43:04 -0500
> > Chuck Lever <chuck.lever@oracle.com> wrote:
> > > 
> > > I don't think dropping the connection will cause the client to 
> > > retransmit sooner.  Clients I have encountered will reconnect and 
> > > retransmit only after their retransmit timeout fires, never sooner.
> > > 
> > 
> > I thought I had noticed the Linux client resending immediately, but it would
> > have been a while ago, and I could easily be remembering wrongly.
> 
> It depends on who closes the connection.
> 
> The client assumes that if the _server_ closes the connection, then it
> may be having resource congestion issues. In order to give the server
> time to recover, the client will delay reconnecting for 3 seconds (with
> an exponential back off).
> 
> If, on the other hand, the client was the one that initiated the
> connection closure, then it will try to reconnect immediately.

So, if I understand Neil's patches right:

	- First we try waiting at least one second for the upcall.
	- Then we try to return JUKEBOX/DELAY.  (But if we're still
	  processing the rpc header we may not have the option.)
	- Then we give up and drop the request.

Upcalls shouldn't normally take a second; so something's broken or
congested, whether it's us or our kerberos server.  So telling the
client we're congested sounds right, as does the client response Trond
describes.

--b.