[jboss-user] [Clustering/JBoss] - Re: JBoss Load Balancing and Embedded Tomcat's

bstansberry@jboss.com do-not-reply at jboss.com
Wed Nov 28 12:04:36 EST 2007

OK. I'm going to be clarify terms a bit then, since "JBoss Application Server" includes the embedded Tomcat and is not a separate and distinct thing.

I think what you are talking about is the web tier within JBoss AS and the EJB tier within JBoss AS.

They both run in the same process so when thinking about this you would want to consider why the EJB tier would have failed when the web tier hasn't, and whether that failure would be something that would cause an EJB request made by the web tier to fail over.  Failover only occurs when the EJB client (in this case in the web tier) determines that an invocation it's made has not successfully reached the server (in this case the EJB tier in the same process.)  Normally this means some sort of communication problem has occurred.  A problem in the EJB itself (e.g. its in some state where it's throwing exceptions, or invocations to it are deadlocking or whatever) does not trigger a failover.  So, if the EJB client and the EJB server are in the same process, the odds of problems occurring that would trigger failover are not high.

Now, to answer your question:  JBoss EJB clients include logic that detect whether the EJB being invoked upon is running in the same VM.  If it is, the logic that causes a remote invocation on the bean is bypassed so the call can use call-by-reference and avoid expensive and unnecessary serialization/deserialization.  Part of the logic that is bypassed is the clustering logic that provides failover.  So, bottom line is you won't get failover.

You can alter this behavior such that the client will allow the call to go remote even though the target bean is running in the same VM.  This comes up from time to time on the forums; search around a bit; how to do it is explained a few times.  I think I wrote a post about a month ago describing it. :)  But, we generally don't recommend doing this, as it adds major overhead to your application -- forces serialization/deserialization and causes calls to go over the network to other VMs when there is a perfectly healthy bean running in the same VM.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108601#4108601

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108601

More information about the jboss-user mailing list