On Thu, Apr 5, 2012 at 14:46, Greg Stein <gstein_at_gmail.com> wrote:
> 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>
>>> > ....
>>> > > >
>>> > > > I've raised issue 4157 to track this problem.
>>> > >
>>> > > Can we at least implement a detection for this situation and fail to
>>> > > 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.
Found the best way: strcmp(ap_show_mpm(), "event")
Received on 2012-04-05 21:03:07 CEST