JMX RMI agent fault tolerance mechanisms

I am using the JMX-RMI agent for message passing. I have a java program which sends a message having a name/id to a set of listener/listeners.Based on the message received by the listeners the client side programs behave accordingly.This piece works fine but I would like to know what kind of fault tolerance is built in into the JMX RMI agent.

If the listener stops accidentally, does JMX restart it or logs the error somewhere,what if the message queue on either side is full. Any documentation which explains the underlying architecture of JMX RMI or the in built fault tolerance mechanism will be appreciated. If it doesn't have any fault tolerance mechanisms, what would be a good way of doing it.

Thanks Much开发者_如何学Go

I am assuming your client side listeners are using the standard javax.management.remote connectors. Without some customization, I would say you can implement some straightforward Fault Detection. For Fault Tolerance you're probably looking at some sort of clustering solution.

There are two layers of connectivity you need to be concerned about:

1. The MBeanServerConnection itself. In other words, if the whole server side JVM terminates, your client side processes need to know.
2. While the server JVM and the subsidiary MBeanServerConnection may continue to be available, the "hosted", the listener/client message forwarder service itself may stop/fail/stall.

For #1, the client processes can register a NotificationListener with the JMXConnector using the addConnectionNotificationListener method. Your local connection will then emit JMXConnectionNotifications on all the following events:

• A new client connection has been opened.
• A client connection has been closed.
• A client connection has failed unexpectedly.
• A client connection has potentially lost notifications. This notification only appears on the client side.

This way, your clients will know when a connection to the server has been established and lost.

For #2, it's a bit more specific to your application, but perhaps you can adapt a simple pattern like this:

When your listener/forwarder service starts, emit a start-notification. When it stops,emit a stopped-notification. The two categories of listeners that would register for these notifications would be:

1. The clients, so they know the service has started/stopped.
2. A server side "watcher" that can listen for a "stop" and restart the service.

Is that more-or-less what you were thinking of ?