jmxPoller extends the dahlia.Poller class. The unique characteristics of JMX
management beans and the dahlia Poller greatly influence design patterns. Still, the two together provide
opportunities for many possibilities.
jmxPoller
is intended to be a long-lived process that can be contacted remotely via JMX
management beans. It supports a
generic command set and attributes that is used to control Poller behavior
while the jmxPoller MXBean is running.
MXBeans themselves provide
at least two interesting abilities:
1.
The
MXBean server that the MXBean is running on maintains a list of MXBean
interfaces that anonymous remote clients can query and exercise. In this
manner, the MXBean acts like a self-contained component.
2.
An
MXBean can provide the MXBean server a list of various notification types. Any MXBean client that has previously
subscribed to the notification can be alerted when any other client raises the
notification event. An example of
this is the MXBean Attribute Changed notification
whereby the act of changing an MXBean attribute endowed in this manner causes
the MXBean server to broadcast a notification.
jmxPoller Design Pattern #1 implements a Poller MXBean in this
fashion:
JPollerInit contains the jPoller package
main function. It initializes
communication with the local JVM MXBean server via
ManagementFactory.getPlatformMBeanServer(). An ObjectName in the required MXBean format and the
jmxPoller MXBean (JXPoller) is created. Both the
ObjectName and the MXBean instance are passed to the MXBean server registration
process.
Since the
jmxPoller MXBean is intended to be a long lived process that should always be
running, the MXBean defines a Daemon
method. The MXBean Daemon method is provided after the MXBean is created
because the MXBean constructor must return before it can be registered.
JXPoller implements the JXPoller MXBean. MXBeans are named after the class that
implements them. JXPoller currently provides START
and STOP commands and Status,
Message Count,
and Poller File
Base attributes.
The dahlia.Poller run() method is
blocking (_stopWhenEmpty
must be explicitly set). In order to cause the MXBean START operation to
return, the run() method call is deferred using
jmxPoller state flags that are polled at the top of
the daemon loop.
The MXBean STOP operation is
implemented by setting the dahlia.Poller _StopWhenEmpty flag
and then destroying the MXBean Poller reference. The hoped for effect is to
stop the dahlia.Poller run() code before _StopWhenEmpty implicitly does. I can probably use some
advice here I think.
Since the STOP operation
destroys Poller references, the START operation creates new dahlia.Poller
instances. The getMsgCount() and Stop() methods
ensure that messages counts are accumulated across new Poller references.
FcgPoller
extends Poller. It does nothing but converts Messages to strings and counts
them.
All the above basically are
trying to take into account the requirement to keep an MXBean running for it to
be available to the JVM (it isn’t stored, when the MXBean exits, so does
all the MXBean server infrastructure) and to interact with an unmodified
dahlia.Poller. I’m still new to java and the app, so I am I will change
all of it if needed (with the hope that they become progressively better).
Also, jmxPoller doesn’t provide any notifications (I started NO NEW
DATA/NEW DATA notifications but haven’t tested them yet)
Jeff