RE: Issue #2580 revisited: Windows unclean TCP close [SEVERE]

Hi Paul --

> [...] it should only take a few minutes for someone to try
> running SSHD + SVNSERVE with SSHD in debug mode and see what the log
> messages say about the handshake with SVNSERVE under the circumstance you
> describe with the RST packet, especially since there are other
> router/network scenarios which would leave a zombie SVNSERVE running.

It might prove interesting, but my guess is that svnserve is happily "awaiting further instructions" from the command line svn (or whatever client) at the other end. Its parent, the server side sshd tunnel, is sitting there saying "What happened? The SSH connection is still open but I'm getting errors from sockets!" What _should_ it do? that's the question. Should it just kill itself and its child svnserve or should it also wait for a while to receive something from the other end ... like maybe a proper SSH closing handshake??? Not clear. Right now it's waiting. It can easily be argued that this is what it should do.

The bottom line is that instantly killing the SSH tunnel at the client sets off a chain of events, all of which go through error recovery paths FOR EVERY SINGLE WORK PACKAGE BETWEEN SVN AND SVNSERVE. My points are (1) that we should not be routinely running through error paths, expecting them to act like something that was intended for production, and (2) having apr instantly kill the tunnel causes (1).

 -- Bob

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410429
Received on 2009-10-22 23:07:01 CEST