CODEWITHSUNDEEP
javajmsapache-cameljmx
Miguel Coquet
Miguel Coquet

Reputation: 300

How to do JMX over JMS?

I need to enhance the JMX interfaces of a distributed java application. The reason for choosing JMX is the simplicity of exposing data. These distributed apps exist in several different machines connected to a JMS server (activemq 5.7) (which in turn is connected to another JMS server to bridge 2 networks, also activemq 5.7).

What I would like to do, is to be able to access the remote JMX interfaces on the individual servers from anywhere on the JMS network. I would nee full JMX access as if accessing through the usual RMI interface. That means every type of action.

I understand I could use lingo to make the remote jmx interfaces talk to the JMS server, and from there my bridge should allow me access to them (assuming its configured correctly).

Is this a good approach? has anyone tried lingo for this purpose? Are there other options out there I may have not found?

A plan B could be to use apache camel RMI module, but it seems like if lingo is an option, it will be much more plug & play than this.

Upvotes: 2

Views: 3455

Answers (3)

Claus Ibsen
Claus Ibsen

Reputation: 55750

Jolokia (http://www.jolokia.org/) is also a great project for remote accessing JMX using REST and JSON. It does this automatic for you. And support batch operations as well. I suggest to take a look at that.

If you use JMX to get AMQ statistics then it offers a plugin, so you can just using JMS messaging to get the stats instead of JMX: http://activemq.apache.org/statisticsplugin.html

Upvotes: 2

Nicholas
Nicholas

Reputation: 16056

I think it's not a bad way to go. The one downside of using JMS that I can think of, off the top of my head, is the dependency on a broker, which most JMS implementations rely on.

On the other hand, it does present some interesting capabilities like discovery, asynchronous JMX invocation and pub/sub multicast style JMX operations where you could issue one operation request and receive back a response from all your MBeanServers.

I am not aware of any actual implementations, but it's probably not too difficult to implement. You simply need a configured client on each target JVM that will:

  1. Listen for JMX requests: The listener will unmarshall the request (which should be an encoding of an MBeanServerConnection method invocation). Use a common topic for pub/sub style invocations, returning the marshalled result to the destination specified in the JMSReplyTo property in the request message. Otherwise, you could allocate a queue per JVM, or pick a unique identifier for each JVM and use message selectors.
  2. If you want to implement JMX notifications, you will need to implement a proxy NotificationListener that registers for the desired notifications and forwards them to the designated JMS destination on receipt.

You may also consider implementing a full blown javax.management.remote implementation which may integrate more smoothly into your environment by virtue of the standard adherence.

I have found the OpenDMK project very useful for extending/implementing JMX servers and clients. The library provides the basic building blocks for implementing a standard JMX remoting solution using a "custom" protocol. Basically, you implement a javax.management.remote.generic.MessageConnection which serves as the transport and invocation mechanism. All JMX invocations, responses and callbacks are serialized into instances of javax.management.remote.message.Message, and they're all Serializable so you should not have any issues writing them into and reading them from JMS ObjectMessages.

A couple of additional benefits you will get from this approach are:

  1. Provided you configiure the classpath correctly, you should be able to connect to your JVMs using any standard JMX tool such as JConsole.
  2. The OpenDMK also provides the ability to federate MBeanServers which makes all your MBeanServer instances appear, and be accessible through one central MBeanServer. This feature requires a standard JMX remoting implementation.
  3. The OpenDMK also implements an interesting service discovery protocol, and it comes in a couple of different flavours including raw multicast and a "phone-home" approach which would mesh nicely with your JMS protocol.

I posted a mavenised project of the OpenDMK here if you're interested.

I am implementing a basic JMX client for java-agents using netty, and it optionally supports asynchronous JMX requests. Responses are delivered through a registered listener which is like a "reverse" MBeanServerConnection. In case this is useful, find the source here.

Upvotes: 3

Peter Lawrey
Peter Lawrey

Reputation: 533442

I would use JMS to discover the URLs of the servers I am interested in and use plain JMX from then on. I don't see the advantage of sending every RMI call over JMS.

Upvotes: 0

Related Questions