On 29.01.2016 15:37, Evgeny Kotkov wrote:
> Daniel Shahaf<danielsh_at_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.
Received on 2016-01-30 10:27:46 CET