On 02.07.2014 15:08, Ivan Zhakov wrote: > On 2 July 2014 17:05, Butler, Stephen <stephen.but...@hamburgsud.com> wrote: >>> -----Original Message----- >>> From: Ivan Zhakov [mailto:i...@visualsvn.com] >>> Sent: Wednesday, July 02, 2014 14:31 >>> To: Butler, Stephen >>> Cc: users@subversion.apache.org >>> Subject: Re: Subversion 1.8 freezes during long updates >>> >>> On 1 July 2014 21:45, Butler, Stephen <stephen.but...@hamburgsud.com> wrote: >>>> Hi folks, >>>> >>>> I'm trying to help users in our corporate network. They currently >>>> use Subversion 1.7 + neon (via TortoiseSVN) because of errors in >>>> checkout/update using Subversion 1.8. During a long checkout or >>>> update, TortoiseSVN 1.8 freezes after downloading a few hundred MBs >>>> of data. The svn command-line client does the same. >>>> >>>> To get more information, I compiled Subversion (within the >>>> TortoiseSVN branches/1.8.x tree) with serf tracing turned up to eleven >>>> (SSL_MSG_VERBOSE, etc). Then the errors no longer occur! Apparently >>>> the extra output changes the timing somehow. But performance is of >>>> course very bad. Less tracing recreates the errors, but without >>>> revealing a smoking gun. >>>> >>>> I attached the Visual Studio debugger to a frozen cmdline client. It >>>> seemed to be looping through impl_pollset_poll (in apr/poll/unix/select.c) >>>> without receiving anything. >>>> >>>> On the Subversion server, the last message in the Apache access log is a >>>> successful file download (matching the last line of client output). The >>>> Apache error log had nothing new. The network has lots of firewalls and >>>> transparent proxies, as was the case in a problem that Branko recently >>>> solved: >>>> >>>> >>>> http://mail-archives.apache.org/mod_mbox/subversion-users/201401.mbox/ >>>> %3C52D6D944.8060308%40wandisco.com%3E >>>> >>>> Should I try to corner the network admins, or is there a client/server >>>> troubleshooting step I've overlooked? >>>> >>>> Thanks for any insights, >>>> >>> Hi Steve, >>> >>> 1. Does the issue reproduce if you force bulk updates using >>> '--config-option=servers:global:http-bulk-updates=yes' command line option >>> or 'SVNAllowBulkUpdates prefer' on the server side? >> Setting either option seems to solve the problem completely. I should have >> read the release notes more carefully! >> >>> 2. Do you have antivirus installed on client computers? >> FWIW, yes, but in this case it was "mostly harmless". >> > It still will be interesting to investigate the issue. Could please > specify what antivirus/firewall used on client computer? Does it have > any active/filtering protection?
We had a case recently, discussed on this list (and verified off-list), where a Cisco ASA with stateful packet inspection turned on would silently close connections to the server in exactly this sort of case; turns out to be a long-standing bug in the IOS firmware that Cisco won't acknowledge. I'm not saying this is the case here, just pointing out that we do have evidence of firewall software or appliances being fundamentally broken. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
