On Wed, Sep 8, 2010 at 9:06 PM, Lieven Govaerts <svn...@mobsol.be> wrote: > On Wed, Sep 8, 2010 at 9:00 PM, Paul Burba <ptbu...@gmail.com> wrote: >> On Thu, May 27, 2010 at 2:42 AM, Lieven Govaerts <svn...@mobsol.be> wrote: >>> Hi, >>> >>> On Mon, May 24, 2010 at 3:51 PM, Lieven Govaerts <svn...@mobsol.be> wrote: >>>> On Sun, May 16, 2010 at 10:38 AM, Stefan Küng <tortoise...@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
