| Apache::RPC::Status - A status monitor similar to Apache::Status for RPC |
Apache::RPC::Status - A status monitor similar to Apache::Status for RPC
# In httpd.conf:
</Location /rpc-status>
SetHandler perl-script
PerlHandler Apache::RPC::Status
</Location>
# In the start-up Perl file:
use Apache::RPC::Status;
The Apache::RPC::Status package is provided as a simple status monitor for XML-RPC servers running in a mod_perl environment, using the Apache::RPC::Server class (or derivative of). Patterned after the status system provided with mod_perl itself, information is broken down into a series of screens providing information ranging from the RPC servers currently configured down to the individual methods provided by the servers.
There are three basic screens provided by the stock Apache::RPC::Status package:
The primary purpose of this status system is to allow for checking the availability and sanity of the RPC servers themselves. For example, if a server is configured to auto-load methods, and automatically check for updates, the status system could confirm that a method is available or is at the correct version.
(Note that auto-loading and auto-updating are done on demand, when a call is made to the method in question. Thus, the status might not reflect changes until at least one call has been made. Further, if there are very many child processes handling the RPC servers, several calls may be necessary to ensure that the child process answering the status request also has the most up-to-date impression of the server.)
This package is implemented as a method handler for Apache/mod_perl. This means that is should be relatively easy to subclass this package to implement an extended version of status reporting, or to provide handlers for phases of the request lifecycle not otherwise addressed.
There are three class methods defined in this package. One is the constructor, the other two are handlers for specific phases in the Apache request lifecycle.
Apache::RPC::Server is assumed. This
value may also be set with the mod_perl PerlSetVar directive. See the
documentation for init_handler, below.
PerlHandler in a location configuration block. It is
invoked by mod_perl as a method handler, thus the first argument is either the
name of the class (in the case of class-method, or static, invocation) or the
object configured as the handler. The second argument is the Apache request
object itself.
This method derives the query parameters for the request from the Apache object, and treats them according to the type of information screen requested:
DECLINED response code.
server, the monitor displays the
server detail screen. In that case, this parameter specifies which server
should be displayed. Servers are given unique identifiers when they are
created, usually derived from the URL path that they are attached to. If the
value here does not match any known servers, a warning is sent to the browser.
method, this calls for the method
detail screen. The provided interface hook to deal with these requests looks
for both the server parameter above and this one, which specifies by name
the method to be laid out in detail. As with the server parameter, if the
value in this parameter does not match any known data, an error is reported to
the browser.
Any additional parameters will be preserved by make_url call detailed below. These are merely the specific ones recognized by the status monitor as written.
ServerClass,
and record the value if it is set. This is used to specifiy the class from
which the RPC server objects are created, if something other than
Apache::RPC::Server. If this information is passed via the serverclass
parameter to the new method above, that value overrides any value
here. However, that requires actually creating an object to use as the
handler, whereas this handler may be used directly, as a static handler. It
would be configured outside of any <Location> blocks, a requirement
for the PerlChildInitHandler phase. It is designed to stack cleanly with
any other handlers for that phase, provided your mod_perl installation
supports stacked handlers.
In addition to the class methods above, the following are provided. In most cases, these do not rely on any data contained within the actual object itself. Many may also be called as static methods (these are so noted). They are provided as a utility, implemented as methods so as to avoid namespace issues:
footer(REQUEST)FLAG
parameter is passed and is any true value, then the resulting URL will be
tailored for use with Apache::Status. The first argument must be either the
original request object as passed by mod_perl, or a reference to a CGI object
created from the request (see CGI for more on the CGI class).
server_summary(SERVER)main_screen.
main_screen.
Some extension may be done without necessarily subclassing this package. The class object are implemented simply as hash references. When a request is received, the screen parameter (see above) is extracted, and used to look up in the hash table. If there is a value for that key, the value is assumed to be a hash reference with at least two keys (described below). If it does not exist, the handler routine declines to handle the request. Thus, some degree of extension may be done without the need for developing a new class, if the configuration and manipulation are done within <Perl> configuration blocks.
Adding a new screen means writing a routine to handle the requests, and then adding a hook into that routine to the object that is the handler for the Apache location that serves RPC status requests. The routines that are written to handle a request should expect four arguments (in order):
The routines are given both the original request object and a query object reference for sake of ease. The query object is already available prior to the dispatch, so there is no reason to have each hook routine write the same few lines to derive a query object from an Apache request. At the same time, the hooks themselves may need the Apache object to call methods on. The query object is an instance of CGI. The flag parameter is passed by the linkage from this status package to Apache::Status. The primary use for it is to pass to routines such as make_url that are sensitive to the Apache::Status context.
The return value from these routines must be a reference to a list of lines of text. It is passed to the print method of the Apache class. This is necessary for compatibility with the Apache::Status environment.
To add a new hook, merely assign it to the object directly. The key is the
value of the screen parameter defined above, and the value is a hash
reference with two keys:
A sample addition:
$stat_obj->{dbi} = {
title => 'RPC-side DBI Pool',
call => \&show_dbi_pool
};
This package is designed to integrate with the Apache::Status package that is a part of mod_perl. However, this is not currently functional. When this has been debugged, the details will be presented here.
This is the newest part of the RPC-XML package. While the package as a whole is now considered beta, this piece may yet undergo some alpha-like enhancements to the interface and such. However, the design and planning of this were carefully considered, so any such changes should be minimal.
Diagnostics are not handled well in this module.
Please report any bugs or feature requests to
bug-rpc-xml at rt.cpan.org, or through the web interface at
http://rt.cpan.org/NoAuth/ReportBug.html. I will be
notified, and then you'll automatically be notified of progress on
your bug as I make changes.
This file and the code within are copyright (c) 2011 by Randy J. Ray.
Copying and distribution are permitted under the terms of the Artistic License 2.0 (http://www.opensource.org/licenses/artistic-license-2.0.php) or the GNU LGPL 2.1 (http://www.opensource.org/licenses/lgpl-2.1.php).
The XML-RPC standard is Copyright (c) 1998-2001, UserLand Software, Inc. See <http://www.xmlrpc.com> for more information about the XML-RPC specification.
Apache::Status, Apache::RPC::Server, RPC::XML::Method
Randy J. Ray <rjray@blackperl.com>
| Apache::RPC::Status - A status monitor similar to Apache::Status for RPC |