SRF Apache2 mod active on non-EG requests, even w/ EG site disabled

[Joe Atzberger]

The osrf_http_gateway Apache module (and possibly osrf_http_translator?) is active on incoming apache requests that are unrelated to Evergreen. This is bad when EG is active (extra cost, failure of logical separation), but more obviously so after after "a2dissite eg.conf", "osrf_ctrl -a stop_all" and "/etc/init.d/ejabberd stop", etc. when the spin-up/ping hits error logs.

Example "curl http://localhost/vufind", error log:

Unable to fopen log file /openils/var/log/gateway.log for writing; logging to standard error
gateway 2013-03-13 20:38:11 [INFO:2306:./osrf_json_gateway.c:91:] Bootstrapping gateway child for requests
[Thu Mar 14 10:57:39 2013] [error] Unable to Bootstrap OpenSRF Client with config /openils/conf/opensrf_core.xml..
[Thu Mar 14 10:57:39 2013] [error] Unable to Bootstrap OpenSRF Client with config (null)..

Those lines repeat for each request (even when the request is otherwise successfully fulfilled by the correct virtualhost).

osrf_http_gateway should make functionality available to EG's vhosts, but it should not affect others. It very much should *not* be initiating additional connections on the basis of unrelated requests. Fixing this would be important to peaceably co-existing with *any* other apache application, including monitoring tools, db admin, VuFind, and serving funny cat pix out of ~/www.

[Galen Charlton (gmc)]

The gateway and HTTP translators attempt to connect to OpenSRF only in their ap_hook_child_init handlers. I'm not able to reproduce getting failed bootstrap log noise with every request, though I do see it whenever Apache forks a new child.

Like most other Apache modules, the gateway and translator decline requests that are not specified to be handled by them via SetHandler or AddHandler, so other than the log noise during child_init, they don't seem to actually get in the way of coexisting other Apache apps.

An easy workaround is to do the equivalent of a2dismod osrf_http_translator and a2dismod osrf_json_gateway, and this could be documented as part of the process for uninstalling OpenSRF.

However, if there's some reason for a webserver to load those modules but not have at least part of Evergreen configured to run on it, I suppose directives could be added to explicitly control whether or not the modules should attempt to bootstrap OpenSRF.