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.
Lieven
Received on 2010-09-08 21:13:44 CEST