On Mon, Aug 27, 2012 at 8:48 PM, Lieven Govaerts <svn...@mobsol.be> wrote: > Hi Johan, > > On Mon, Aug 27, 2012 at 2:44 PM, Johan Corveleyn <jcor...@gmail.com> wrote: >> On Mon, Aug 20, 2012 at 12:43 PM, Lieven Govaerts <svn...@mobsol.be> wrote: >>> On Mon, Aug 20, 2012 at 10:18 AM, Johan Corveleyn <jcor...@gmail.com> wrote: >>>> On Sun, Aug 19, 2012 at 1:53 PM, Lieven Govaerts <svn...@mobsol.be> wrote: >>>>> Hi Johan, >>>>> >>>>> >>>>> as you seem to be the only one encountering issue 4174, would you mind >>>>> testing attached serf patch? >>>>> You'll have to update serf trunk to r1627 to apply it cleanly. >>>>> >>>>> It fixes the issue for me on Windows 7 with svn trunk and serf trunk. >>>>> While I have tested the patches on Mac OS X too, I couldn't reproduce >>>>> the original problem. >>>> >>>> Great, it works! >>>> >>>> - svn trunk@1374802 with serf trunk@1627 without patch: verified that >>>> I could still reproduce the original issue. >>>> >>>> - svn trunk@1374802 with serf trunk@1627 with your patch: the issue >>>> did not occur anymore. I could successfully export the dreaded large >>>> working copy from our repository over https. I tried a couple of times >>>> to be sure, and there was no problem anymore. >>>> >>> >>> Okay, thanks for testing! I've committed the fix in serf r1628. >> >> Hi Lieven, >> >> I'm afraid the issue may not be completely fixed yet. After further >> testing with even larger exports and checkouts, I again got the same >> error: >> >> [[[ >> C:\Temp\svnperf>timeit svn export https://playsvn/svn/testrepo/trunk >> trunk-exp10 -q >> svn: E730053: Error retrieving REPORT (730053): An established >> connection was aborted by the software in your host machine. >> start: 2012-27-08 14:22:02,88 >> end : 2012-27-08 14:24:59,70 >> total runtime: 176820 ms >> ]]] >> >> This export should yield 87064 files in 12849 directories. The one >> above errored out after 17343 files and 2878 dirs. >> >> But it's much harder to reproduce now (unfortunately): often the >> export will complete just fine. It may be related to network >> conditions: yesterday during the day I first ran into this. Then late >> at night I tried for hours to reproduce it again, but no errors >> anymore. Today during the day (with more traffic going on) tried >> again, and got the error again. >> >> Can you take another look for similar problems, other error conditions >> of the same nature, ... ? >> > > I've been working on this issue for the last few evenings. > > The trigger is that the servers aborts the SSL connection. If you > follow the ssl stream in Wireshark (or...), you'll notice that the > server sends an SSL Alert (close notify), followed by a reset of the > connection. > > This will happen from time to time on a large checkout or export. I've > found it very easy to trigger by forcing the server to initialize a > re-handshake for a location in the repository, e.g.: > > <Location /svn/v8copy/trunk/test/mjsunit> > DAV svn > .. > SSLCipherSuite RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW > </Location> > > As soon as the export/checkout reaches this location, the server will > trigger a rehandshake. > > The patch I've committed previously does the right thing, iff serf > manages to process the SSL Alert first, before the connection is > reset. In this case we can reset the connection on the client and > continue with a new connection. > > The problem is that serf is not always capable to first process the > SSL alert before the connection is reset. Serf can be reading a lot of > data before it passes it to SSL, serf can be writing a new request > etc. > > So I'm working on a patch that handles connection aborts and resets > correctly. My work in progress already handles these correctly, > however I've run into a memory corruption when resending a PROPFIND > request, so I'd like to fix that first. > > I'll keep you posted.
Great, thanks. -- Johan