"No locks available" how do I fix it?
>svn ci -m "svn lock trouble" . svn: Commit failed (details follow): svn: Can't get exclusive lock on file '/media/stuart/svn/ca/db/txn-current-lock': No locks available I had done a svn mkdir and svn moved a bunch of files to it plus adding some more - is that relevant? I tried a svn ci . but the program hung after the edit pop up, and I killed it. Since then I can not get it past the No locks available message. I have tried all the possible relevant admin actions I could find in the manual, including recover (which also dies for lack of lock). lslocks does not show any rmlocks does nothing svn status -u sees no problem and so on. I am running Ubuntu 10.10 Maverick Meerkat and the distribytion is up to date. svn --version svn, version 1.6.12 (r955767) compiled Jul 5 2010, 16:53:32 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). 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 Help.
Circular cleanup/checkout problem using Subversion 1.7
In attempting to pull down a copy of the trunk to my PC, I inadvertently accessed a file in the Subversion repository that was created on a non-Windows machine. The file has a name containing a less-than sign, which is illegal in DOS/Windows. This caused a circular condition in which Svn was unable to complete processing of the checkout, and further cannot execute its cleanup utility. Thus, cleanup cannot run because of a checkout problem; checkout cannot run because of a cleanup problem. Ultimately, the problem really is that the file cannot be renamed to its given, but illegal, name. Subversion client is TortoiseSVN (1.7.1, Build 22161 – 64 Bit). Windows 7 PC. Attempting to run a Svn Update causes this to appear: Update Failed! Error Previous operation has not finished; run ‘cleanup’ if it was interrupted Error Please execute the ‘Cleanup’ command. The operation failed. An attempt to cleanup results in this dialog box message: Cleanup failed to process the following paths: C:\Users\myusername\svn\trunk\research Working copy ‘C:\Users\myusername\svn\trunk\research’ locked. ‘C:\Users\myusername\svn\trunk’ is already locked. Two suggested workarounds -- deleting the working directory, and attempting the cleanup at the trunk level -- have the same results. I do see that Svn retrieved the file’s contents to a temp folder (C:\users\myusername\svn\.svn\tmp), but cannot rename that to the non-conforming filename. Do I need to delete my entire working directory? I am essentially dead in the water here, as I cannot do any Subversion work in any directory. On site, work is being done to rename or delete the offending files, but that will not help me in my local build area on my PC. Suggestions welcome. Stuart Strickland Software Engineer sstrickl...@carnegielearning.com Toll Free: (888) 851-7094 x195 FAX: (412) 690-2444 [http://resources.carnegielearning.com/images/CarnegieLogoGT.png] Revolutionary Math Curricula. Revolutionary Results. Carnegie Learning, Inc. | 437 Grant St. 20th Floor | Pittsburgh, PA 15219 www.carnegielearning.com<http://www.carnegielearning.com>
Subversion Exception!
--- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at https://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.14.0\ext\subversion\subversion\libsvn_wc\wc_db.c' line 10238: assertion failed (svn_dirent_is_absolute(local_abspath)) --- OK --- Brian Stuart | Engineering Manager Smith Micro Software, Inc. | 120 Vantis, Suite 350, Aliso Viejo, CA 92656 | www.smithmicro.com<http://www.smithmicro.com/> direct: +1 949 362 2331 | main +1 949 362 5088 [cid:image004.jpg@01D19EF9.40501350]<http://www.smithmicro.com/> [cid:image006.jpg@01D19EF7.A9A63D90]<https://www.facebook.com/smithmicro> [cid:image008.jpg@01D19EF7.A9A63D90] <https://www.linkedin.com/company/smith-micro-software> [cid:image010.jpg@01D19EF7.A9A63D90] <https://twitter.com/smithmicro?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor> [cid:image012.jpg@01D19EF7.A9A63D90] <https://plus.google.com/+smithmicro/posts> [cid:image007.jpg@01D19EF9.40501350] <https://www.youtube.com/user/SmithMicroSoftware>
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* >> > >
Incorrect 1.8.10 source in source download
All, [I'm not subscribed; please cc me in responses.] Just a quick report: the source download for 1.8.10 seems to be broken: the JavaHL souce has compile errors (due to a missing static enum Inheritance in MergeInfo that was introduced in r1499639, whereas the tagged source is r1485055). *The tagged 1.8.10 source on the main repo is fine and correct.* So it looks like the source download build got corrupted somehow. Regards, Stuart -- Stuart Rossiter stuart.p.rossi...@gmail.com Research Fellow: EPSRC Care Life Cycle Project http://www.southampton.ac.uk/clc
Re: Incorrect 1.8.10 source in source download
Brane, > Where did you download the source tarball from? The 'official' one from https://subversion.apache.org/download/. (Namely the 1.8.10 ZIP one: http://www.mirrorservice.org/sites/ftp.apache.org/subversion/subversion-1.8.10.zip .) > JavaHL definitively works in 1.8.10; that's tested on several platforms. > However, you may have received an unofficial or hacked tarball from somewhere. Yes, I'm using it fine; just wanted to flag that the 'official' source is corrupt (maybe the tar-based ones are OK). Stuart On 6 November 2014 16:39, Branko Čibej wrote: > On 06.11.2014 16:27, Stuart Rossiter wrote: > > All, > > > > [I'm not subscribed; please cc me in responses.] > > > > Just a quick report: the source download for 1.8.10 seems to be > > broken: the JavaHL souce has compile errors (due to a missing static > > enum Inheritance in MergeInfo that was introduced in r1499639, whereas > > the tagged source is r1485055). *The tagged 1.8.10 source on the main > > repo is fine and correct.* So it looks like the source download build > > got corrupted somehow. > > Where did you download the source tarball from? JavaHL definitively > works in 1.8.10; that's tested on several platforms. However, you may > have received an unofficial or hacked tarball from somewhere. > > -- Brane > > -- Stuart Rossiter stuart.p.rossi...@gmail.com Research Fellow: EPSRC Care Life Cycle Project http://www.southampton.ac.uk/clc
Re: Incorrect 1.8.10 source in source download
Brane, [Not subscribed; please cc me on any replies.] Sorry, I think I've wasted your time. I tried to reproduce it at home and I can't. I suspect that I somehow mixed two releases (probably unzipping 1.8.10 code into existing HEAD code or something similar); it was a long day... Many apologies. (Turns away to hide reddening face...) Stuart P.S. If anyone is still reading (and does not yet hate me), I had a tangential question about whether there is anything on Windows which provides a binary install of the JavaHL JAR *and* native libraries (as occurs in Linux packages such as libsvn-java on Ubuntu). It seems that SlikSVN installs *only* the native libraries. (Hence why I was building a 'paired' JAR manually from SVN source.) I put up a Stack Overflow question about it, so any answers might be best going there: http://stackoverflow.com/questions/26782416. Yes, I do have a silly Stack Overflow name. On 6 November 2014 17:42, Branko Čibej wrote: > On 06.11.2014 18:18, Stuart Rossiter wrote: > > Brane, > > > > > Where did you download the source tarball from? > > > > The 'official' one from https://subversion.apache.org/download/. > > > > (Namely the 1.8.10 ZIP > > one: > http://www.mirrorservice.org/sites/ftp.apache.org/subversion/subversion-1.8.10.zip > .) > > > I just checked the ZIP file from this mirror against the one in our > master distribution source, and compared its contents with the tarballs. > There are only expected differences (those are related to the build > system, which is different on *nix than on Windows). The sources, > including JavaHL sources, are all identical. > > Could you perhaps share a build log that shows specific errors that you > saw during compilation? > > -- Brane > > -- Stuart Rossiter stuart.p.rossi...@gmail.com Research Fellow: EPSRC Care Life Cycle Project http://www.southampton.ac.uk/clc
