Alternate plugin handling

David A. Webster DAWEBSTER at UP.COM
Tue May 10 17:57:25 UTC 2011


This is another topic I have discussed with the JON/RHQ product team at 
JBossWorld and via conference call;  the notion of a finer grained plugin 
model for RHQ.

RHQ and JON were initially designed to support standard, stock containers, 
JBoss, Tomcat, etc...  These containers have a consistency across the 
Enterprise.  We can count on every JBoss server to be, well, a JBoss 
server no matter where it is deployed.   It might have a few 
customization's like Java startup options (-Dxxx) and a modified classpath 
and few custom MBeans deployed, but bottom line, one JBoss or Tomcat 
instance looks pretty much like any other instance.

The result is, from the server perspective, the plugin's are "pushed", or 
at the agent side, the agent simply polls the JON server to periodically 
pull any new or update plugins.  The assumption being, that whatever is 
running on the managed node is consistent with what is running everywhere 
and all the registered plugins are pulled down to every agent attached to 
the JON server instance.

As we have discovered here, JON/RHQ is also a potentially very powerful 
tool for managing stand alone Java process as well.  It's provisioning 
mechanisms and ability to write custom plugins, in particular JMX plugins 
makes it very attractive as a management platform for stand alone Java. We 
code most of our services as Stand Alone using Spring IOC, thus no need to 
host in a container.

The problem here is, the processes can all be very different from one 
another, in particular, each set of processes may have a very unique set 
of MBeans to manage that set.  There is no high level of consistency from 
instance to instance other than they are all running in a JVM.  Therefore, 
the global push (or from the agent perspective, the universal pull of 
everything) kind of breaks down.  If I have 250 stand alone JVMs, each 
with a custom set of MBeans, each with it's own plugin to support those 
MBeans, on each agent node, I get my plugin, but also get 249 other 
plugins I have no interest in and lord knows what that does to my agent 
JVM Heap or resource utilization?

Proposal would be the development of a new kind of plugin, the "private" 
plugin, where you drop the plugin into the agent plugin deploy folder, not 
the server, the agent reports the plugin to the server, the server exposes 
it in inventory discovery, but the plugin only lives at the one agent it 
was deployed to.  What you end up with is the standard agent plugin that 
is today "public", meaning it is blasted out to every agent the server 
knows about, but another "private" one that handled and only exists on the 
agent it was deployed to.

Not sure how much rework to the agent plugin system this would entail, but 
it would make JON a much better tuned product to support large stand alone 
Java environments like out.


David Webster
Union Pacific Railroad
Lead Architect-Web Infrastructure
Systems Engineering
Phone: (402) 544-1094 | Email: dawebster at up.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/rhq-devel/attachments/20110510/f8327ff3/attachment.html 


More information about the rhq-devel mailing list