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
>> 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)
As per delta editor contract... one can not open two files at once on
the same editor drive, so no issue.
Received on 2011-05-13 16:50:53 CEST