On Mon, Aug 27, 2012 at 8:48 PM, Lieven Govaerts <svnlgo_at_mobsol.be> wrote:
> 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.
Great, thanks.
--
Johan
Received on 2012-08-27 21:16:39 CEST