On Thu, Dec 1, 2016 at 8:08 AM, Jim Jagielski <j...@jagunet.com> wrote:
> My question is how do the beans, for example, from mod_bmx_vhost
> get displayed via mod_bmx_status?
>
> I understand that one queries mod_bmx for specific beans, but at
> the end of the day people still want/need a comprehensize
> mod_status-like display. My expectation would be that mod_bmx_status
> would provide that.
>
mod_bmx is the hub module which handles the bmx-handler generator.
Configuration is as straightforward as compiling in or loading mod_bmx.so
and following a typical server-status handler config;
<Location /bmx>
SetHandler bmx-handler
Require ip 127.0.0.1
</Location>
What mod_bmx reports depends on who hooks into it. You can run it
by only loading mod_bmx_status, or only mod_bmx_vhost, or any
combination of multiple providers. An obvious new extension would
be mod_proxy_balancer pool load reporting.
mod_bmx_status hooks into this framework by setting a server-lifetime
bean indicating that ServerStatus is extended or not, and then hooks
into the mod_bmx query hook during the pre-config phase;
APR_OPTIONAL_HOOK(bmx, query_hook, bmx_status_query_hook, NULL, NULL,
APR_HOOK_MIDDLE);
Our mod_bmx_status query_hook handler is a fairly typical 'handler',
of data instead of content;
static int bmx_status_query_hook(request_rec *r,
const struct bmx_objectname *query,
bmx_bean_print print_bean_fn)
We don't want to refresh our data if the query indicates that the request
to the bmx-handler excluded server-status data, so there's a short circuit
right off the bat. Provided some subset of server-status data is needed,
this function continues by populating the data for mod_bmx to present
(which it can further filter by item name without help from the extensions).
Finally the query fn in mod_bmx_status performs the callback indicated
through its invocation to unspool the data in presentation format, which
lives back in mod_bmx and behaves identically for every bmx extension.
Adding the properties by type takes all of the onus off of each extension
to know how to represent them once stored. E.g. our query_hook function
can be as simple as;
/* create the bean */
bmx_bean_create(&bmx_status_bean, bmx_status_objectname, r->pool);
bmx_bean_prop_add(bmx_status_bean,
bmx_property_string_create("ServerName",
ap_get_server_name(r),
r->pool)); print_bean_fn(r,
bmx_status_bean);
For Stefan's and others concerns, it would probably be most useful
for Doug or Aaron to explain how they came to the bean datum model
for representing bmx's results.
.
