Reconnecting remote MBean proxies

**mbabauer** · Feb 28th, 2006, 04:11 PM

I am using JSR-160 support in Spring, with the Spring MBean Proxy on the client. When the server is up, everything is gravy. But, if the server is down when my client starts, or the server goes down, all heck breaks loose.

My client is a MBean server, with several MBeans called Gauges running and registered, watching certain attributes on other registered MBeans. When the gauges hit a value thats out of whack, they send a javax.management.Notification to another MBean that serves as the central point for all Notifications. This central point (called the NotificationConcentrator) then has a refernce to this remote MBean proxy, using JSR-160 jmxmp, to send to a remote collector. The idea here being that there are multiple of these clients running, each dumping Notification events into this central location, which all in turn forward to this central server for trending and tracking. I do need to mention that most of this code is a "retrofit" from previous code that was VERY JBoss 3.2.x specific, using JBoss's RMIAdapter, so much of this code is, and will remain, untouched.

I can get around the initial startup issue by setting the proxy as lazy-init=true, but it fails as soon as the NotificationConcentrator tries to get his remote proxy, which he gets through dependency injection.

Also, is there a way I can get it to "reconnect" on failure? Last, is there some prefered method for caching the failed requests and resending them when the connection is reestablished?

Thanks

**Costin Leau** · Mar 1st, 2006, 03:36 AM

I think these details depend a lot on the JMX implementation. I guess some sort of reconnecting feature could be added to the MBean proxy for such cases but IMO the caching and local storing of messages in case of failures (jms basically) does not fall under Spring JMX.
I haven't had such a need so I can't provide advices but I suggest you investigate what other jmx implementations and solutions provide - I would expect this problem to be discussed somewhere. I suggest to start with JMX mailing list.

**mbabauer** · Mar 1st, 2006, 12:46 PM

I tried switching the protocol for my JSR-160 to the MX4J SOAP connector, but I get the following on my server side:

Code:

java.lang.IncompatibleClassChangeError: : method  is not an interface method

The soap request that generated that error is:

Code:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
<ns1:connectionId xmlns:ns1="http://mx4j.sourceforge.net/remote/soap/1.0" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next" soapenv:mustUnderstand="1" xsi:type="soapenc:string">soap:  0x1</ns1:connectionId>
</soapenv:Header>
<soapenv:Body>
<ns2:fetchNotifications xmlns:ns2="http://mx4j.sourceforge.net/remote/soap/1.0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<sequence href="#id0"/>
<maxNumber href="#id1"/>
<timeout href="#id2"/>
</ns2:fetchNotifications>
<multiRef xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" id="id2" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:long">60000</multiRef>
<multiRef xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" id="id1" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:int">25</multiRef>
<multiRef xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" id="id0" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:long">-1</multiRef>
</soapenv:Body>
</soapenv:Envelope>

And the response:

Code:

<html>
<head>
<title>Error 500 : method  is not an interface method</title>
</head>
<body>
<h2>HTTP ERROR: 500</h2>
<pre>: method  is not an interface method</pre>
<p>RequestURI=/services</p>
<p>
<i>
<small>
<a href="http://jetty.mortbay.org">Powered by Jetty://</a>
</small>
</i>
</p>

What I don't get is that I never call this fetchNotifications method, so I have no idea why its trying to call it. The method I am trying to execute is "processNotification". Not only am I not calling fetchNotifications, but dont even have it anywhere in my codebase. As far as I can tell, its comming from the actual JMX (MX4J) pieces.

My question is, why is the proxy trying to execute this anyway? Does it need to have all the notifications for something I am not aware of?

**Costin Leau** · Mar 1st, 2006, 02:55 PM

Seek advice from the mx4j list - the problem might occur because you are using SOAP and both parties need to have the class definitions that are going over the 'wire'. Again, I might be completely wrong. Try using hessian or burlap - they provide a nice alternative.

Thread: Reconnecting remote MBean proxies

Thread Tools

Display

Reconnecting remote MBean proxies

Tried using SOAP

Posting Permissions