Hi Johan,
On Mon, Aug 27, 2012 at 2:44 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Mon, Aug 20, 2012 at 12:43 PM, Lieven Govaerts <svnlgo_at_mobsol.be> wrote:
>> On Mon, Aug 20, 2012 at 10:18 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>>> On Sun, Aug 19, 2012 at 1:53 PM, Lieven Govaerts <svnlgo_at_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_at_1374802 with serf trunk_at_1627 without patch: verified that
>>> I could still reproduce the original issue.
>>>
>>> - svn trunk_at_1374802 with serf trunk_at_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.
> --
> Johan
Lieven
Received on 2012-08-27 20:49:46 CEST