"cdelory" wrote :
| In the mean time, I figured out another workaround: use the "regular" JRMP
proxy factory, which registers a local JNDI name on each target server, and go through
HA-JNDI to perform the cluster lookup of one of my registered services. The bad side here
is that I cannot really load-balance the service invocations: the HA-JNDI lookup always
chooses the first valid response in the response list.
Do you mean this is because the mbean is only deployed on a few servers in your cluster,
so most lookups involve a cluster-wide search on the server side, and those cluster wide
searches are not returning evenly balanced results? That wouldn't surprise me at
all.
If that's not what you mean, hmm, the lookup calls should be load balanced.
anonymous wrote : So, sooner or later, I'll migrate to your workaround or wait the
next release.
OK. Note that I marked the issue as resolved for 4.2.4 and 5.0.1, but it could be a real
long time before any 4.2.4 comes out; perhaps only the discovery of some critical security
issue in 4.2.3 would drive the release of a 4.2.4.
anonymous wrote : I still have the following question, which in fact is not really related
to any clustering issue: can I spare this extra MBean declaration (the proxy factory), but
still access my remote MBean service through its remote interface (HAServiceRemote in your
example)? Or maybe I want to have one's cake and eat it?.
No, to make invocations against the HAServiceRemote type in a remote VM you need an object
in that VM that implements the interface and then passes the call back to the server via
some transport. That is, you need a proxy. :-)
If you are willing to give up calling against the interface and just make detyped JMX
invocations, you can use the AS's JMX Remoting service aka the RMIAdaptor.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196006#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...