On Thu, Dec 1, 2016 at 12:33 PM, Jim Jagielski <j...@jagunet.com> wrote:
>
> > On Dec 1, 2016, at 12:53 PM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> >
> > 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);
> >
> >
>
> OK, this is the point I have the question about. From what
> I can see, mod_bmx_status creates bmx_status_bean, adds stuff
> to it, and then prints it out.
>
> But how does it get access to, for example, the beans created and
> populated in mod_bmx_vhost? I understand that if you KNOW what
> beans you are looking for, you can query them via mod_bmx, but
> how do you know what beans have been added.
>
The beans are individually reflected to the print_bean_fn by each of
the consumers who registered against the query_hook.
mod_bmx then iterates the name of the bean and the property names
to filter out what is wanted. If *everything* is wanted, simply don't give
any query args to the bmx-handler request.
> Right now, for example, we have a simple hook that mod_socache_redis
> (for example) hooks into and once mod_status is done, it loops
> through all registered hooks. But I don't see any similar type of
> functionality in mod_bmx_status which allows mod_bmx_status to
> reproduce the full status information that mod_status currently
> does.
>
Note that mod_bmx_status entries focus on what most management
frameworks are looking for, so thus far, it doesn't deliver an entire
dataset per connection or worker thread. It certainly could, of course.
One thing not implemented, json (or even bean) arrays, which might
become very useful for tabular data from status, balancer, etc.
So yeah, other modules create their beans. Fine. But how
> do those beans get "registered" in mod_bmx_status so that they
> can actually be displayed?
Again, it simply iterates the entire contents of each bean presented
to it's own print_bean_fn callback. If you have a look at;
https://github.com/hyperic/mod_bmx/blob/master/modules/bmx/mod_bmx.h
that should give you a somewhat higher altitude perspective on Aaron's
API design.
More background;
https://github.com/hyperic/mod_bmx/blob/master/README-BMX.txt
