On 29.01.2016 15:37, Evgeny Kotkov wrote:
Daniel Shahaf<danie...@apache.org>  writes:

Well, it isn't consensus, but there's an old fallback we can use:
pick an agreed-upon third party and let him decide.

So let's ask a mod_dav/mod_dav_svn dev for his opinion and do what he says.
It seems like we still don't have a consensus here.  I still say we should
just go with (2) and have the problem solved.  But since we were unable to
agree on that, this issue is now tracked as SVN-4616:

   https://issues.apache.org/jira/browse/SVN-4616

One thing worth adding is that there's also a problem with how we log actions
from mod_dav_svn callbacks.

Well, approving r1721285 and r1725180 will go a long
way reducing the impact of that issue for most users.
In particular, those setting MaxMemFree to "eat all my
memory".

Within a callback, we lack the information about the state of the operation.
As one example, deadprops.c:db_first_name() calls dav_svn__operational_log().
While handling <allprop/> depth 1 PROPFIND requests, db_first_name() is called
once per every walked entry.  Every subsequent call rewrites previously set
r->subprocess_env values.  Hence, the actual log entry is determined by the
last walked entry, and that's incorrect.  And all these values are allocated
in the request pool, thus triggering unbounded memory usage.

I think that this part of the problem can't be solved properly without
reimplementing the PROPFIND in mod_dav_svn.
Having the problem fixed in mod_dav itself (e.g. see
https://bz.apache.org/bugzilla/show_bug.cgi?id=48130)
would make future maintenance "their problem". Forking
the code makes it "ours", more specifically: *yours*.

Given that the issue seems to be known for 5+ years
and patches for it are available for 3+ years now,
responsiveness is obviously bad. Did you contact them
before suggesting the fork and what was their response?

Concerning the fork, I think Ivan made a good point saying
that we already did something similar for httpv2. So, how
much of mod_dav_svn would we want to folk (property
handling only or all the remainder as well) and how much
code would that add to mod_dav_svn (50%?, more?, less?).

If the total addition is significantly smaller than mod_dav_svn,
maintaining it should be feasible after the first couple of
years of stabilization.

-- Stefan^2.

Reply via email to