On 05/13/2011 07:51 PM, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: kameshj_at_apache.org [mailto:kameshj_at_apache.org]
>> Sent: vrijdag 13 mei 2011 14:22
>> To: commits_at_subversion.apache.org
>> Subject: svn commit: r1102690 - in /subversion/trunk/subversion:
>> libsvn_ra_serf/replay.c tests/cmdline/svnsync_tests.py
>>
>> Author: kameshj
>> Date: Fri May 13 12:22:15 2011
>> New Revision: 1102690
>>
>> URL: http://svn.apache.org/viewvc?rev=1102690&view=rev
>> Log:
>> Fix for issue3870 "File descriptor leaks during svnsync".
>>
>> Before this fix, all of destination delta editor's interfaces
>> are called with *LONG* living pool(dst_rev_pool living for one full revision).
>>
>> This makes it a memory bloat and bloat of other OS resources like
>> file descriptors to live as long the dst_rev_pool.
> I'm pretty sure this fixes this issue, but shouldn't the file pool live inside a revision pool? (Or maybe in a directory pool, that lives in, ... etc. etc.)
That is how it is in neon.
Current State of serf's *state* handling do not have room for that
hierarchy or revision->directory->file.
I thought to implement similar hierarchy as a part of this patch.
But having closely looked at the neon's code with respect to the file
handling portions of editor drive, I felt simple file_pool that gets
cleared upon before starting a new file seemed a simpler approach.
Anyways as I stated in the original mail... Similar problems could
remain for directories having huge number of sub directories.... anyway
I will write a testcase and fix on a permanent problem.
> Without looking at the code I would have expected that serf might operate on multiple files at once. (But I assume our test suite would have caught that by now)
>
> Bert
>
As per delta editor contract... one can not open two files at once on
the same editor drive, so no issue.
With regards
Kamesh Jayachandran
Received on 2011-05-13 16:50:53 CEST