Greg Stein <gstein@lyra.org> writes:
> > I traced this with a network sniffer, and indeed, we're right in the
> > middle of a PUT of svndiff data (with a Content-Length of 31116 bytes)
> > -- then suddenly a bunch of "RST" (reset) TCP windows, and poof, the
> > connection is dead.
>
> I'd need to see who first issued that RST, but I'm guessing the Apache side.
Yup.
> That means Apache closed the connection. I would guess there is some kind of
> timeout associated with the connection, and Apache doesn't realize that it
> is in use. i.e. something needs to "ping" it
Timeout? In microseconds? I mean, when I import over DAV, I see a
string of "Added ..." lines flying by at high speed, and then
*instantly* terminated by a broken pipe.
> > When I run this process in gdb, we get a SIGPIPE (broken pipe) right
> > inside libc, in the middle of attempt to write() data to a socket.
> > The gdb traceback shows us inside ne_socket.c:sock_fullwrite() line
> > 440. Neon is simply writing 1024 bytes of data to a socket.
>
> First order of business is to get Neon to set a signal handler to ignore
> SIGPIPE, and look for EPIPE from that write() call. We can then properly
> bubble the error up.
Oooooh. Mmmmm.
> It probably does not make sense for you to spend time tracing through Apache
> to figure out why it decides to close the socket. Maybe there are some other
> items to fix?
Definitely.
> Looks like I need to revamp the props right quick -- that would appear to be
> our biggest blocker. I ought to be able to do that this week.
Cool. But don't think we're going to stop studying the network code. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:40 2006