Clustering for JBoss Remoting

[linpeizhang]

We are using JBoss Remoting to create our new middleware system. So far, it's working great. One reason we choose JBoss Remoting is clustering. However, I cannot find any document about how to implement JBoss Remoting in a clustered environment. What I am looking for is server farm, load balancing and fail over. Would you please point me to some documents or sampel codes? Thanks!

[tom.elrod]

Sounds like, based on what you are looking for, EJB3 (which runs on top of remoting) might be a better option for you than just JBoss Remoting. You can find more information about EJB3 at http://www.jboss.com/products/ejb3.

However, if still want to use just JBoss Remoting, there is an example of using failover via regular POJOs using remoting transporter at http://labs.jboss.com/portal/jbossremoting/docs/transporter/transporter_sample.html#d0e326.

[linpeizhang]

Thanks, Tom! I will take a look at both approach and let you know what I figure out. Thanks!

[linpeizhang]

I looked through the clustered transporter example. It looks great. However, just to confirm, it can only handle fail-over. It CANNOT handle load balancing. I mean round roubin the invocations among clustered servers. Can you confirm that? Thanks!

[linpeizhang]

I tested out the example of the JBoss Remoting transporter. The failover seems to have a bug. I am using JBoss Remoting 1.4.0 Beta

Here is the sequence I tried:

1. Start SocketServer
2. Start HTTPServer
3. Start RMIServer
4. Start Client. I can see all the requests from Client is processed correctly.
5. Stop SocketServer. The failover works. The Client requrests are now processed by the HTTPServer.
6. Start SocketServer again. Now, all the Client requests went to the new SocketServer instead of the HTTPServer. I consider it's bug.
7. Stop SocketServer again. The Client requests cannot be processed any more. I got a lot of exception in the Client side indicating "connection refused". I am not sure why it didn't failover to the HTTPServer or the RMIServer.