On Wed, Sep 8, 2010 at 9:06 PM, Lieven Govaerts <svnlgo_at_mobsol.be> wrote:
> On Wed, Sep 8, 2010 at 9:00 PM, Paul Burba <ptburba_at_gmail.com> wrote:
>> On Thu, May 27, 2010 at 2:42 AM, Lieven Govaerts <svnlgo_at_mobsol.be> wrote:
>>> Hi,
>>>
>>> On Mon, May 24, 2010 at 3:51 PM, Lieven Govaerts <svnlgo_at_mobsol.be> wrote:
>>>> On Sun, May 16, 2010 at 10:38 AM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> During the last few days, I've changed TSVN to link against the svn trunk.
>>>>> The speed is much better now, so thanks for that. It's not as fast as the
>>>>> 1.6.x branch yet but it's usable.
>>>>>
>>>>> About my problem:
>>>>> serf is now the default DAV lib svn uses. But with serf I get tons of app
>>>>> crashes (serf calls abort() - something I won't discuss here anymore since
>>>>> you all should know my opinion about that).
>>>>> For example: a simple checkout of the svn trunk crashed after about 5
>>>>> seconds. Subsequent updates did too - I had to run cleanup and restart the
>>>>> update 27 (!!) times until I had the svn trunk on my harddrive.
>>>>>
>>>>> I'm using serf 0.6.1, but the same problem existed with 0.3.1. I updated to
>>>>> 0.6.1 yesterday hoping it would solve the problem, but apparently didn't.
>>>>
>>>
>>> I have prepared serf 0.6.2 with this fix at:
>>> http://serf.googlecode.com/svn/branches/0.6.x
>>>
>>> Can anyone of you reporting this problems test if this makes them go away?
>>>
>>> Checkout takes plenty of memory with ra_serf, way more than when using
>>> ra_neon. I suspect these changes didn't make that worse, rather the
>>> choice of pools for file-related requests in ra_serf (not the serf
>>> library). I'll look into this.
>>
>> Hi Lieven,
>>
>> Did you ever investigate checkout's memory usage with serf? It seems
>> to still be a problem with serf 0.7.0, see
>> http://subversion.tigris.org/issues/show_bug.cgi?id=3684#desc4.
>>
>
> Yes, that's why started that issue an hour ago :) (although I know
> see the issue wasn't really assigned to myself.)
>
>> I'm seeing some benefits with bumping
>> serf/buckets/allocator.c:STANDARD_NODE_SIZE from 128 to 256, but the
>> results vary...going to dump what I have found thus far into issue
>> #3684.
>
> The real issue is serf r1388. This rev solved a bucket lifetime issue
> causing regular crashes, at the cost of changing the mechanism used by
> ssl to keep decrypted but not yet handled data.
>
> The solution I'm looking at now is to undo r1388, and solve the
> crashes in another way.
>
Serf trunk 1408 solves this issue for me and for Paul.
Lieven
Received on 2010-09-09 08:06:26 CEST