On 05/13/2011 07:51 PM, Bert Huijben wrote:
-----Original Message-----
From: kame...@apache.org [mailto:kame...@apache.org]
Sent: vrijdag 13 mei 2011 14:22
To: comm...@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
