[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC/PATCH] Handling PROPFIND in mod_dav_svn (was: Re: Issue with browsing a SVN 1.9.2, schema 7, packed, repository)

From: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Tue, 5 Jan 2016 19:08:41 +0300

Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:

>> I'm aware of two possible ways of solving the problem:
>>
>> (1) Fix mod_dav, adjust mod_dav_svn accordingly
>>
>> (2) Reimplement PROPFIND in mod_dav_svn
>>

[...]

> Wait a minute. Isn't "we have few active committers" a reason for
> choosing (1) over (2)? I would naïvely expect "rewrite it" to be more
> expensive to implement/maintain than "patch it".
>
> Similarly, playing devil's advocate, if the issue exists since 2003,
> then presumably it's not urgent to fix, and waiting until httpd-2.6 is
> released might not be a major setback.

[...]

> I'm not too happy at basically saying I prefer (1) over (2) when you've
> already written a 2000-line patch for (2)... but maybe (2) _is_ the
> better way to go and I just don't see it yet. Enlighten me ☺

I did explore option (1) prior to (2), and spent a reasonable amount of time
trying to prepare the mod_dav's part of the patch.

Option (1) requires a major overhauling of how mod_dav works with pools, and
there are just too many things that we'd need to deal with. Basically, every
relevant pool usage needs to be examined, updated and propagated to the
mod_dav's public API.

Then, even if we pulled that off in httpd, I don't think that these changes
would become a part of 2.2.x and 2.4.x. And the necessity of waiting or
upgrading to httpd 2.6.x is a major setback, since I think that, for example,
the 2.2.x series is still widely adopted.

Consuming unbounded amounts of memory or crashing is a serious issue,
and people report it to us. There's quite a history of plugging PROPFIND
memory leaks in mod_dav_svn in response to such reports — see [1, 2], for
instance. However, while the root cause is still there, the problem can be
re-triggered by a variety of factors. In this particular case, the trigger is
the replacement of the dynamically-sized caches with a fixed-size membuffer
cache in 1.7, because now series of cache misses or uncacheable objects can
lead to performing allocations in the long-living request pool.

Compared with (1), option (2) has known complexity and should fix the problem
irrespectively of the httpd version, and that's why I proposed we do it.

[1] https://issues.apache.org/jira/browse/SVN-2000
[2] https://svn.apache.org/r859602

Regards,
Evgeny Kotkov
Received on 2016-01-05 17:09:12 CET

This is an archived mail posted to the Subversion Dev mailing list.