On Thu, Apr 5, 2012 at 14:21, Daniel Shahaf <danielsh_at_elego.de> wrote:
> Greg Stein wrote on Thu, Apr 05, 2012 at 14:14:53 -0400:
>> On Apr 5, 2012 2:10 PM, "Daniel Shahaf" <danielsh_at_elego.de> wrote:
>> >
>> > Greg Stein wrote on Thu, Apr 05, 2012 at 14:05:31 -0400:
>> > > On Apr 5, 2012 6:46 AM, "Philip Martin" <philip.martin_at_wandisco.com>
>> wrote:
>> > ....
>> > > >
>> > > > I've raised issue 4157 to track this problem.
>> > >
>> > > Can we at least implement a detection for this situation and fail to
>> start?
>> > > Maybe mod_dav_svn would query the mpm type, and the fs type. We could at
>> > > least backport that to 1.7.x pretty quickly.
>> > >
>> >
>> > No need. 1.7.x doesn't compile against 2.4 for other reasons (API
>> > changes). I've patched them on trunk but vetoed the backport pending
>> > resolution of the BDB hangs.
>>
>> That prevents somebody from using BDB with the 2.4 worker mpm.
>
> Philip reported seeing tests pass with unmodified HEAD on worker.
>
> Anyway I won't object to adding a version check on httpd (at configure-
> or run-time). We know it'll hang..
It would need to be at run-time since the MPM type and the FS type is
not known at configuration time.
Oh, shoot... there might be multiple repositories, with mixed types.
Thus, it is really a per-request check. I wonder if we can even ask
the FS what type it is without opening/allocating this per-thread
stuff. Even if we could, it would imply needing to send a 500 response
back to the client. That's not a very nice situation :-/
Ah. I see it: svn_fs_type(). A call to that in
mod_dav_svn/repos.c:get_resource(), and we can bail out with an error.
I'm just not sure what values to examine in some ap_mpm_query() calls
(ref: ap_mpm.h). There may be a single query (eg. AP_MPMQ_IS_ASYNC)
that identifies the event MPM.
Cheers,
-g
Received on 2012-04-05 20:47:21 CEST