On Thu, Apr 5, 2012 at 14:21, Daniel Shahaf <danie...@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" <danie...@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.mar...@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
