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@up.com