You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2001/09/10 19:42:02 UTC
imports failing over dav.
Greg Stein <gs...@lyra.org> writes:
> > * 455: import doesn't work over ra_dav
>
> No idea.
Here's everything I know about this bug. First, here's one of many
reproducible examples:
[sussman@kepler:~/projects/test/foo]$ svn import http://newton.collab.net/repos/sussman-repo ~/projects/subversion-M3 svnny
Username:
Password:
Adding ./svnny
Adding ./svnny/ac-helpers
Adding ./svnny/ac-helpers/config.guess
Adding ./svnny/ac-helpers/config.sub
Adding ./svnny/ac-helpers/berkeley-db.m4
Adding ./svnny/ac-helpers/get-neon-ver.sh
Adding ./svnny/ac-helpers/gnu-diff.sh
Adding ./svnny/ac-helpers/gnu-patch.sh
Adding ./svnny/ac-helpers/install.sh
Adding ./svnny/ac-helpers/svn-apache.m4
Adding ./svnny/ac-helpers/svn-macros.m4
Broken pipe
No matter which tree I decide to import, after a few (anywhere from 5
to 30) files have been PUT, we get mysterious "Broken Pipe" -- and a
dead transaction left on the server.
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.
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.
More frustrating, not a single interesting thing is logged in the
httpd error_log. The access_log shows nothing but the PUT request.
I'm not sure how to debug from here. Do I need to run httpd inside
gdb? How to proceed?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: imports failing over dav.
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Sep 10, 2001 at 04:46:33PM -0500, Ben Collins-Sussman wrote:
>...
> > 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. :-)
I hope not. It is finally good to have somebody help out while I'm busy
working on some other stuff. Progress can happen even while I'm distracted.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: imports failing over dav.
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@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
Re: imports failing over dav.
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Sep 10, 2001 at 02:42:02PM -0500, Ben Collins-Sussman wrote:
>...
> Here's everything I know about this bug. First, here's one of many
> reproducible examples:
Yup. I saw the same thing.
>...
> 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.
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
> 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.
> More frustrating, not a single interesting thing is logged in the
> httpd error_log. The access_log shows nothing but the PUT request.
IMO, the answer is probably in Apache's connection-timeout logic.
> I'm not sure how to debug from here. Do I need to run httpd inside
> gdb? How to proceed?
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?
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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: imports failing over dav.
Posted by Ben Collins-Sussman <su...@collab.net>.
Joe Orton <jo...@manyfish.co.uk> writes:
> My bet is this is a persistent connection handling problem in Apache 2.
For those of us who don't much about Apache, can you explain how it's
working? Hypothesize about what's going on?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: imports failing over dav.
Posted by Joe Orton <jo...@manyfish.co.uk>.
My bet is this is a persistent connection handling problem in Apache 2.
The debug traces for import look something like this:
new connection
-> OPTIONS
<- 200
-> MKACTIVITY
<failed to read status line, start new connection>
-> retry the MKACTIVITY
<- 201
-> PROPFIND
<- 207
-> retry the PROPFIND
<failed to read status line, start new connection>
and so on, basically losing the connection every couple of requests.
neon fails gracefully if this happens when it's reading from the socket,
but if it's writing a request body to the socket, we get a SIGPIPE.
I was seeing these with checkouts too. When I turn off persistent
connections in ra_dav, these problems go away, so I'll commit that as a
temporary workaround, and try and work up a simple repro case against
Apache 2.0.
(Thanks to Ben for setting up a test repos so I can play with this!)
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org