I'll take a look at the forensics and the packet trace. The server is on a LAN - I don't believe there are any proxies involved, but I'm not the guy who has to put together the servers. I'm just the guy that has to communicate with them. I'll ask about that. A tracert, though, shows no hops between the client and the server. Subversion provides atomic commits so, although I see no evidence on the server side, I assume that's because the commit process failed so Subversion actually committed nothing. And, to be honest, I can't be completely sure the commit fails mid-stream, but I See a lot of generated output indicating the process is doing what it's supposed to (adding and removing files from the repository) and then the failure message. That's what leads me to think it's a mid-stream failure. If someone who knows more than I do (should be a lot of those people about) can offer another suggestion, I'm all ears. Thanks. On 8/21/06, Joshua Slive <joshua@xxxxxxxx> wrote:
On 8/21/06, Rob Wilkerson <r.d.wilkerson@xxxxxxxxx> wrote: > All - > > I know this is somewhat off-topic and I apologize for that, but I'm > not having any luck on the Subversion mailing list so I thought I'd > ask the question from this end and see if someone can give me any > suggestions on where to look and/or possible causes. > > I'm trying to commit a large code base merge using Subversion over > HTTP through Apache 2.2.2. The commit seems to be rolling along > nicely when suddenly it simply fails with a message that it could not > connect to the server. The Apache error and access logs > (/var/log/httpd/error_log and /var/log/httpd/access_log) give no > indication that it was even aware of the transaction, much less that > it failed. Smaller commits, on the other hand, work fine. > > I've tried - at the suggestion of a member of the Subversion mailing > list - to disable the XML request body checking (LimitXMLRequestBody > 0), but that made no difference at all. Are there any other > directives that might prevent a connection from being severed? Is > there any way to be sure that it's apache severing the connection? > Can any other process sever an HTTP connection? > > I'm running: > FC5 > Apache 2.2.2 > SELinux is disabled > Subversion 1.3.2 > mod_python 3.2.8 > (I think those are all of the relevant line items) > > Again, I apologize if this is too far off-topic, but I'm desperate. I > had to at least give it a shot. Doesn't seem that far off-topic to me. If you are saying that the request seems to partially complete from the client side, but you see no evidence of it at all in the apache error or access logs, that may suggest an apache process crash. If that is the case, you can use mod_log_forensic to verify that the server is crashing, and you can use the instructions here to try to get a backtrace giving details of the problem: http://httpd.apache.org/docs/2.2/mod/mod_log_forensic.html http://httpd.apache.org/dev/debugging.html#crashes If an apache process crash is not the problem, then you should look at a packet trace: http://httpd.apache.org/dev/debugging.html#tcpdump It is, of course, possible that there is a proxy inbetween you and the server that could be messing up the connection. One way around that is to use SSL, since proxies are less likely to mess with SSL connections. Joshua. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
-- Rob Wilkerson --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|