Slow VM, svn client drops connection with FIN packet
I am seeing exactly this issue: https://groups.google.com/forum/#!topic/subversion_users/AZ4M62Qwmjc but do not find a bug report for it in the database. The linked bug is for something similar but unrelated. Can I file this? ...Stu stumacdonald@stumacdonald-VirtualBox:~/src/ianywhere$ svn --version svn, version 1.7.13 (r1516569) compiled Aug 27 2013, 09:06:07 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme
Re: Slow VM, svn client drops connection with FIN packet
If someone can point me at a Ubuntu-compatible package, I'm more than happy to upgrade. Last time I looked (within the last two months) I was unable to find anything later than what I'm running. I'd rather not spend the time compiling from source if I can avoid it. Please elucidate "capture traces". I already have a Wireshark capture of the failure. I see exactly what the poster saw: the client drops the connection with an unexplained [FIN, ACK]. This is easily recreated for me: I run this update once a morning, and see the failure about 3 days out of 5. I've been working with my internal IT group, but they haven't been able to help much. They did have me add 'http-timeout = 180" to the .subversion/servers [global] section; this cut down the failures to about 1 out of 5 days. Agreed; getting the bug fixed is the victory. However, this is clearly two bugs: 1) the error message is wrong, 2) the client is dropping the connection. Those need to be in the bug database unless they are already present, or already fixed. Neither seemed to be the case when I posted. ...Stu On Mon, Dec 16, 2013 at 11:59 AM, Mark Phippard wrote: > On Mon, Dec 16, 2013 at 10:56 AM, Stuart MacDonald < > stuartm.cod...@gmail.com> wrote: > >> >> I am seeing exactly this issue: >> https://groups.google.com/forum/#!topic/subversion_users/AZ4M62Qwmjc but >> do not find a bug report for it in the database. The linked bug is for >> something similar but unrelated. Can I file this? >> >> ...Stu >> >> stumacdonald@stumacdonald-VirtualBox:~/src/ianywhere$ svn --version >> svn, version 1.7.13 (r1516569) >> compiled Aug 27 2013, 09:06:07 >> > > > Subversion 1.8 has an entirely new HTTP networking layer. So the first > thing you should do is start with the latest version (1.8.5) so you can see > if the problem is either fixed or manifests differently. You will likely > also need to capture traces etc. to have any chance of getting this solved > since it is not something that can be easily recreated. > > Finally, getting something filed in the issue tracker is not a victory. > This mailing list is the best place to get attention for your problem and > interact with others etc. > > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/ >
Re: Slow VM, svn client drops connection with FIN packet
The link I provided is *exactly* what I'm seeing, so I didn't see the need to repeat that post. I'm in a VM, the client drops the connection with an erroneous [FIN, ACK], just after the TCP window opens up again. Hm, one detail I can provide now that's not in that post: U directory/file1 U directory/file2 svn: E175002: REPORT of '/svn/repos//!svn/me': Could not read response body: connection was closed by server (http://) I don't know what's on the server side, and may not be able to find out, but I'll inquire. Hm, actually the network trace shows "Server: nginx/1.0.5". Client operation is 'svn up'. What else would you like me to do/provide? ...Stu On Mon, Dec 16, 2013 at 12:05 PM, Ben Reser wrote: > On Mon Dec 16 07:56:32 2013, Stuart MacDonald wrote: > > > > I am seeing exactly this > > issue: > https://groups.google.com/forum/#!topic/subversion_users/AZ4M62Qwmjc > > but do not find a bug report for it in the database. The linked bug is > for > > something similar but unrelated. Can I file this? > > > > ...Stu > > > > stumacdonald@stumacdonald-VirtualBox:~/src/ianywhere$ svn --version > > svn, version 1.7.13 (r1516569) > > compiled Aug 27 2013, 09:06:07 > > > > Copyright (C) 2013 The Apache Software Foundation. > > This software consists of contributions made by many people; see the > NOTICE > > file for more information. > > Subversion is open source software, see http://subversion.apache.org/ > > > > The following repository access (RA) modules are available: > > > > * ra_neon : Module for accessing a repository via WebDAV protocol using > Neon. > > - handles 'http' scheme > > - handles 'https' scheme > > * ra_svn : Module for accessing a repository using the svn network > protocol. > > - with Cyrus SASL authentication > > - handles 'svn' scheme > > * ra_local : Module for accessing a repository on local disk. > > - handles 'file' scheme > > Before reporting an issue you really ought to try it with the most > recent version of Subversion (1.7.14 and 1.8.5). Since 1.8.0 we only > use the serf http-library. If you can trigger the same issue with > 1.8.5 then that's likely a sign that we aren't tending the TCP > connections as we should (vs the neon http library that your version > output shows you're using with 1.7.13). Another point is that you > really should provide more details here. What versions of httpd and > svn are on the server side? What client operation(s) are you having > the issue with. > > Without a lot more research on your part the bug isn't likely to get > much interest. >
Re: Slow VM, svn client drops connection with FIN packet
IT says we have: nginx 1.05 with plans to move to 1.3.9 svn is 1.7.7 (we are not planning to upgrade for some time) ...Stu On Mon, Dec 16, 2013 at 12:45 PM, Stuart MacDonald wrote: > The link I provided is *exactly* what I'm seeing, so I didn't see the need > to repeat that post. I'm in a VM, the client drops the connection with an > erroneous [FIN, ACK], just after the TCP window opens up again. > > Hm, one detail I can provide now that's not in that post: > U directory/file1 > U directory/file2 > svn: E175002: REPORT of '/svn/repos//!svn/me': Could not read > response body: connection was closed by server (http://) > > I don't know what's on the server side, and may not be able to find out, > but I'll inquire. Hm, actually the network trace shows "Server: > nginx/1.0.5". Client operation is 'svn up'. > > What else would you like me to do/provide? > > ...Stu > > > > On Mon, Dec 16, 2013 at 12:05 PM, Ben Reser wrote: > >> On Mon Dec 16 07:56:32 2013, Stuart MacDonald wrote: >> > >> > I am seeing exactly this >> > issue: >> https://groups.google.com/forum/#!topic/subversion_users/AZ4M62Qwmjc >> > but do not find a bug report for it in the database. The linked bug is >> for >> > something similar but unrelated. Can I file this? >> > >> > ...Stu >> > >> > stumacdonald@stumacdonald-VirtualBox:~/src/ianywhere$ svn --version >> > svn, version 1.7.13 (r1516569) >> > compiled Aug 27 2013, 09:06:07 >> > >> > Copyright (C) 2013 The Apache Software Foundation. >> > This software consists of contributions made by many people; see the >> NOTICE >> > file for more information. >> > Subversion is open source software, see http://subversion.apache.org/ >> > >> > The following repository access (RA) modules are available: >> > >> > * ra_neon : Module for accessing a repository via WebDAV protocol using >> Neon. >> > - handles 'http' scheme >> > - handles 'https' scheme >> > * ra_svn : Module for accessing a repository using the svn network >> protocol. >> > - with Cyrus SASL authentication >> > - handles 'svn' scheme >> > * ra_local : Module for accessing a repository on local disk. >> > - handles 'file' scheme >> >> Before reporting an issue you really ought to try it with the most >> recent version of Subversion (1.7.14 and 1.8.5). Since 1.8.0 we only >> use the serf http-library. If you can trigger the same issue with >> 1.8.5 then that's likely a sign that we aren't tending the TCP >> connections as we should (vs the neon http library that your version >> output shows you're using with 1.7.13). Another point is that you >> really should provide more details here. What versions of httpd and >> svn are on the server side? What client operation(s) are you having >> the issue with. >> >> Without a lot more research on your part the bug isn't likely to get >> much interest. >> > >
Re: Slow VM, svn client drops connection with FIN packet
Thanks, I'll pass it along. It mentions that commit access is required to exploit this though, so I think IT will probably ignore this if they haven't already patched it. ...Stu On Mon, Dec 16, 2013 at 2:20 PM, Ben Reser wrote: > On 12/16/13 11:08 AM, Stuart MacDonald wrote: > > svn is 1.7.7 (we are not planning to upgrade for some time) > > This doesn't help with your issue but if you need ammo to convince IT to > upgrade: > https://subversion.apache.org/security/CVE-2013-4131-advisory.txt > > If it's a distribution package it might have been patched without changing > the > version number. >
Re: Slow VM, svn client drops connection with FIN packet
On Mon, Dec 16, 2013 at 12:45 PM, Mark Phippard wrote: > On Mon, Dec 16, 2013 at 12:31 PM, Stuart MacDonald < > stuartm.cod...@gmail.com> wrote: > >> If someone can point me at a Ubuntu-compatible package, I'm more than >> happy to upgrade. Last time I looked (within the last two months) I was >> unable to find anything later than what I'm running. I'd rather not spend >> the time compiling from source if I can avoid it. >> > > http://subversion.apache.org/packages.html#ubuntu > Yeah. The Ubuntu packages don't have either 1.7.14 or 1.8.5. The WANdisco packages require registration. What I said stands, there are no current Ubuntu-compatible packages. So, compiling from sources. ...Stu
Re: Slow VM, svn client drops connection with FIN packet
On Monday, December 16, 2013 1:45:11 PM UTC-5, Branko Čibej wrote: > > So your server is using an nginx proxy, and your 1.7 client doesn't work > with it. The thing to do is to try to reproduce this with 1.8, and if it's > reproducible, it's still most likely a proxy bug (nginx 1.0.5 is rather > old). Reporting this to the server administrator would be the next step. > The Wireshark trace shows clearly and conclusively this is a bug in the client. The client drops the connection by sending a FIN packet unexpectedly. ...Stu
Re: Slow VM, svn client drops connection with FIN packet
On Mon, Dec 23, 2013 at 3:51 PM, Lieven Govaerts wrote: > to be clear, you've tested: > - svn 1.7.13 with ra_neon, svn 1.7.14 with ra_neon and 1.8.5 with ra_serf. > - to an svn 1.7.7 server > - over http, with nginx 1.0.5. as intermediate proxy > - running 'svn up' > - on an Ubuntu guest (version __) using Virtualbox (version > __) on host OS . > > Can you fill in the blanks? > - on an Ubuntu guest (version 12.10) using Virtualbox (version 4.2.12 r84980) on host OS Windows 7 64-bit Enterprise SP1 For VirtualBox the guest extensions are installed; the adapter is set in NAT mode. The error "The server sent a truncated HTTP response body." you're > seeing from ra_serf, means that ra_serf is busy reading a response > from the server but all data isn't arriving. > The network trace shows the data arriving: svn 1.8.5: 496958625.44475700010.222.3.8810.14.10.85HTTP1434 Continuation or non-HTTP traffic 496959625.44483600010.14.10.8510.222.3.88TCP549415 > http [ACK] Seq=2713 Ack=612899776 Win=1760768 Len=0 496960625.44487800010.14.10.8510.222.3.88TCP54[TCP Window Update] 9415 > http [ACK] Seq=2713 Ack=612899776 Win=1762048 Len=0 496961626.11133100010.14.10.8510.222.3.88TCP549415 > http [FIN, ACK] Seq=2713 Ack=612899776 Win=1762048 Len=0 496962626.1248910.222.3.8810.14.10.85TCP60http > 9415 [ACK] Seq=612899776 Ack=2714 Win=12288 Len=0 svn 1.7.14: 444658437.94194600010.222.3.8810.14.10.32HTTP1434 Continuation or non-HTTP traffic 444659437.94199500010.14.10.3210.222.3.88TCP5460442 > http [ACK] Seq=2151 Ack=550721697 Win=542208 Len=0 444660439.77498200010.14.10.3210.222.3.88TCP54[TCP Window Update] 60442 > http [ACK] Seq=2151 Ack=550721697 Win=1966336 Len=0 444661440.0201710.14.10.3210.222.3.88TCP5460442 > http [FIN, ACK] Seq=2151 Ack=550721697 Win=1966336 Len=0 444662440.0335810.222.3.8810.14.10.32TCP60http > 60442 [ACK] Seq=550721697 Ack=2152 Win=10240 Len=0 One thing to note: a while ago my IT dept had me set "http-timeout=180" to see if that fixed the problem. The 1.7.14 network capture is with that set from last Fri. The 1.8.5 is without it set from this morning. I found that setting it did reduce the frequency of occurrence, but not resolve it entirely; I went from failing about 3 out of 5 mornings to 1 out of 5. I've removed it (restored to using the default values) in order to have more frequent failures for quicker testing. We have seen this caused by proxies tampering with the response data. > In this case I suppose the connection is shut down unexpectedly first, > which ra_serf interprets as 'the connection closed, but I didn't get > all data for this response yet" => error. > I would doubt that the proxy is tampering with the data, otherwise svn would fail all the time, yes? Note that the client is sending the [FIN, ACK], not the server. > You have tested two versions of subversion, each with their own http > client implementation (serf and neon). Both libraries have been > implemented completely independently by different people, without > sharing code. I find it difficult to believe that both libraries have > the same bug, but ok, it's not impossible. > Agreed, it seems unlikely, but not impossible. I'd look first at the svn layer that uses the libraries. I took some time last Fri to see what was 180 seconds prior to the FIN packet in the trace (this is the 1.7.14 failure): 289223259.41852100010.222.3.8810.14.10.32HTTP1434 Continuation or non-HTTP traffic 289224259.41858300010.14.10.3210.222.3.88TCP5460442 > http [ACK] Seq=2151 Ack=358465616 Win=1280 Len=0 289225259.64941500010.222.3.8810.14.10.32HTTP1334 [TCP Window Full] Continuation or non-HTTP traffic 289226259.85560500010.14.10.3210.222.3.88TCP54[TCP ZeroWindow] 60442 > http [ACK] Seq=2151 Ack=358466896 Win=0 Len=0 289227259.86801800010.222.3.8810.14.10.32HTTP1334 [TCP Window Full] [TCP Retransmission] Continuation or non-HTTP traffic 289228*REF*10.14.10.3210.222.3.88TCP66[TCP ZeroWindow] 60442 > http [ACK] Seq=2151 Ack=358466896 Win=0 Len=0 SLE=358465616 SRE=358466896 2892290.38385800010.14.10.3210.222.3.88TCP54[TCP Window Update] 60442 > http [ACK] Seq=2151 Ack=358466896 Win=2062848 Len=0 2892300.39800500010.222.3.8810.14.10.32HTTP1434 Continuation or non-HTTP traffic which yields 444658178.07389500010.222.3.8810.14.10.32HTTP1434 Continuation or non-HTTP traffic 444659178.07394400010.14.10.3210.222.3.88TCP5460442 > http [ACK] Seq=2151 Ack=550721697 Win=542208 Len=0 444660179.90693100010.14.10.3210.222.3.88TCP54[TCP Window Update] 60442
Re: Slow VM, svn client drops connection with FIN packet
On Mon, Dec 23, 2013 at 4:47 PM, Stuart MacDonald wrote: > I took some time last Fri to see what was 180 seconds prior to the FIN > packet in the trace (this is the 1.7.14 failure): > 289223259.41852100010.222.3.8810.14.10.32HTTP1434 > Continuation or non-HTTP traffic > 289224259.41858300010.14.10.3210.222.3.88TCP54 > 60442 > http [ACK] Seq=2151 Ack=358465616 Win=1280 Len=0 > 289225259.64941500010.222.3.8810.14.10.32HTTP1334 > [TCP Window Full] Continuation or non-HTTP traffic > 289226259.85560500010.14.10.3210.222.3.88TCP54[TCP > ZeroWindow] 60442 > http [ACK] Seq=2151 Ack=358466896 Win=0 Len=0 > 289227259.86801800010.222.3.8810.14.10.32HTTP1334 > [TCP Window Full] [TCP Retransmission] Continuation or non-HTTP traffic > 289228*REF*10.14.10.3210.222.3.88TCP66[TCP > ZeroWindow] 60442 > http [ACK] Seq=2151 Ack=358466896 Win=0 Len=0 > SLE=358465616 SRE=358466896 > 2892290.38385800010.14.10.3210.222.3.88TCP54[TCP > Window Update] 60442 > http [ACK] Seq=2151 Ack=358466896 Win=2062848 Len=0 > 2892300.39800500010.222.3.8810.14.10.32HTTP1434 > Continuation or non-HTTP traffic > which yields > 444658178.07389500010.222.3.8810.14.10.32HTTP1434 > Continuation or non-HTTP traffic > 444659178.07394400010.14.10.3210.222.3.88TCP54 > 60442 > http [ACK] Seq=2151 Ack=550721697 Win=542208 Len=0 > 444660179.90693100010.14.10.3210.222.3.88TCP54[TCP > Window Update] 60442 > http [ACK] Seq=2151 Ack=550721697 Win=1966336 Len=0 > 444661180.15211900010.14.10.3210.222.3.88TCP54 > 60442 > http [FIN, ACK] Seq=2151 Ack=550721697 Win=1966336 Len=0 > 444662180.16552900010.222.3.8810.14.10.32TCP60http > > 60442 [ACK] Seq=550721697 Ack=2152 Win=10240 Len=0 > > If the time ref is set at (wireshark-)packet 289227 then the FIN packet > would be at 179.something elapsed. There are a lot of TCP zero windows in > the trace though, that one isn't special AFAICT. There's plenty before and > after it. > > If someone can let me know what the default for http-timeout is for > 1.8.5/ra_serf, I'll do the same check in this morning's failure and see > what's there. > Some googling <http://mail-archives.apache.org/mod_mbox/subversion-commits/201211.mbox/%3c20121120183435.0e86a2388...@eris.apache.org%3E>reveals that the default timeout is likely to be 600 seconds. Let's see what we have there (this is the 1.8.5 failure): 70825.46218500010.222.3.8810.14.10.85TCP1434[TCP segment of a reassembled PDU] 70925.4625810.14.10.8510.222.3.88TCP549415 > http [ACK] Seq=2713 Ack=753855 Win=1280 Len=0 71025.70726900010.222.3.8810.14.10.85TCP1334[TCP Window Full] [TCP segment of a reassembled PDU] 71125.90722900010.14.10.8510.222.3.88TCP54[TCP ZeroWindow] 9415 > http [ACK] Seq=2713 Ack=755135 Win=0 Len=0 712*REF*10.14.10.8510.222.3.88TCP54[TCP Window Update] 9415 > http [ACK] Seq=2713 Ack=755135 Win=3328 Len=0 7130.0138610.222.3.8810.14.10.85TCP1434[TCP segment of a reassembled PDU] which yields 496958599.34497700010.222.3.8810.14.10.85HTTP1434 Continuation or non-HTTP traffic 496959599.34505600010.14.10.8510.222.3.88TCP549415 > http [ACK] Seq=2713 Ack=612899776 Win=1760768 Len=0 496960599.34509800010.14.10.8510.222.3.88TCP54[TCP Window Update] 9415 > http [ACK] Seq=2713 Ack=612899776 Win=1762048 Len=0 496961600.01155100010.14.10.8510.222.3.88TCP549415 > http [FIN, ACK] Seq=2713 Ack=612899776 Win=1762048 Len=0 496962600.0251110.222.3.8810.14.10.85TCP60http > 9415 [ACK] Seq=612899776 Ack=2714 Win=12288 Len=0 So that's interesting that it's also at a TCP zero window, but like the 1.7.14 failure, there's nothing special about that one; there are several before it and many after it. >From 2013-12-17, 1.7.13 (WANdisco again), http-timeout=180, ra_neon: 380006238.31042100010.222.3.8810.14.10.32HTTP1434 Continuation or non-HTTP traffic 380007238.31050100010.14.10.3210.222.3.88TCP5412926 > http [ACK] Seq=2151 Ack=464948988 Win=1280 Len=0 380008*REF*10.222.3.8810.14.10.32HTTP1334[TCP Window Full] Continuation or non-HTTP traffic 3800090.20008800010.14.10.3210.222.3.88TCP54[TCP ZeroWindow] 12926 > http [ACK] Seq=2151 Ack=464950268 Win=0 Len=0 3800100.4560710.222.3.8810.14.10.32TCP60[TCP Keep-
Re: Slow VM, svn client drops connection with FIN packet
I don't have access to the server log, but you can see from the wireshark capture that the *client* closed the connection (look for the RST packet), not the server. The error of "socket closed" is consistent with that. I suspect that there's an issue handling the "http-timeout" timer; it gets triggered during a TCP zero window situation, and then not canceled properly, and then it fires, closing the socket. That would also fit the data of the bug being in 1.6 (reported by someone else, but I linked to it in my original post), 1.7 and 1.8; it's a bug in svn's handling of the underlying HTTP interaction layer, and not in that layer or the server or somewhere else. I could be wrong. When I look at the evidence so far, that's what I see. ...Stu On Tue, Jan 14, 2014 at 6:33 AM, Philip Martin wrote: > stuartm.cod...@gmail.com writes: > > > I have another failure, with some debug info, and some updates. > > > > We're switching to a different system for this particular repository, so > I > > may or may not be able to continue debug efforts. :-( > > > > Since there's no debug info available for the svn 1.8 client, I haven't > > been running that. > > > > I went a full week without a failure, which I suspect is due to the > > enormous amount of debugging that neon-debug-mask=255 produces, so this > > week I dialed it back to 127 and got a failure on the first try. > > > > Here's the latest failure. First up, the debug info: > > Got 8192 bytes. > > XML: Parsing 8192 bytes. > > XML: char-data (235) returns 0 > > XML: xmlParseChunk returned 0 > > Reading 8192 bytes of response body. > > Got 6600 bytes. > > XML: Parsing 6600 bytes. > > XML: char-data (235) returns 0 > > XML: xmlParseChunk returned 0 > > Reading 8192 bytes of response body. > > Aborted request (-3): Could not read response body > > That message comes from ne_request.c and the -3 is NE_SOCK_CLOSED > defined in ne_socket.h: > > #define NE_SOCK_CLOSED (-3) > /* Connection was reset (e.g. server crashed) */ > > > sess: Closing connection. > > sess: Connection closed. > > Request ends, status 200 class 2xx, error line: > > Could not read response body: connection was closed by server > > Running destroy hooks. > > Request ends. > > svn: E175002: REPORT of '/svn/repos//!svn/me': Could not read > > response body: connection was closed by server (http://) > > sess: Destroying session. > > sess: Destroying session. > > What does the server error log show? > > -- > Philip Martin | Subversion Committer > WANdisco // *Non-Stop Data* >
Re: Slow VM, svn client drops connection with FIN packet
's close, and, given the long gap no packets occur at FIN - 67 seconds. I'm going to keep trying random timeout values. ...Stu On Tue, Jan 14, 2014 at 9:27 AM, Stuart MacDonald wrote: > I don't have access to the server log, but you can see from the wireshark > capture that the *client* closed the connection (look for the RST packet), > not the server. The error of "socket closed" is consistent with that. > > I suspect that there's an issue handling the "http-timeout" timer; it gets > triggered during a TCP zero window situation, and then not canceled > properly, and then it fires, closing the socket. > > That would also fit the data of the bug being in 1.6 (reported by someone > else, but I linked to it in my original post), 1.7 and 1.8; it's a bug in > svn's handling of the underlying HTTP interaction layer, and not in that > layer or the server or somewhere else. > > I could be wrong. When I look at the evidence so far, that's what I see. > > ...Stu > > > On Tue, Jan 14, 2014 at 6:33 AM, Philip Martin > wrote: > >> stuartm.cod...@gmail.com writes: >> >> > I have another failure, with some debug info, and some updates. >> > >> > We're switching to a different system for this particular repository, >> so I >> > may or may not be able to continue debug efforts. :-( >> > >> > Since there's no debug info available for the svn 1.8 client, I haven't >> > been running that. >> > >> > I went a full week without a failure, which I suspect is due to the >> > enormous amount of debugging that neon-debug-mask=255 produces, so this >> > week I dialed it back to 127 and got a failure on the first try. >> > >> > Here's the latest failure. First up, the debug info: >> > Got 8192 bytes. >> > XML: Parsing 8192 bytes. >> > XML: char-data (235) returns 0 >> > XML: xmlParseChunk returned 0 >> > Reading 8192 bytes of response body. >> > Got 6600 bytes. >> > XML: Parsing 6600 bytes. >> > XML: char-data (235) returns 0 >> > XML: xmlParseChunk returned 0 >> > Reading 8192 bytes of response body. >> > Aborted request (-3): Could not read response body >> >> That message comes from ne_request.c and the -3 is NE_SOCK_CLOSED >> defined in ne_socket.h: >> >> #define NE_SOCK_CLOSED (-3) >> /* Connection was reset (e.g. server crashed) */ >> >> > sess: Closing connection. >> > sess: Connection closed. >> > Request ends, status 200 class 2xx, error line: >> > Could not read response body: connection was closed by server >> > Running destroy hooks. >> > Request ends. >> > svn: E175002: REPORT of '/svn/repos//!svn/me': Could not read >> > response body: connection was closed by server (http://) >> > sess: Destroying session. >> > sess: Destroying session. >> >> What does the server error log show? >> >> -- >> Philip Martin | Subversion Committer >> WANdisco // *Non-Stop Data* >> > >
