This is dependant on the LoadBalancing policy that is set when you deploy your bean (see the doco). Furthermore, if you never you use the same home/remote proxy, the policy is reinitialized (because it is a new proxy) and may re-start always using the same target node.
I have a similar but different experience with jbossha-httpsession.
Before I deployed the clustering stuff, the iis-redirect.dll load balancer was using round-robbin to load balance a new user to an app server. Sticky load balancing was in effect so that if I started 10 browsers, on average 5 users were 'stuck' to server A and 5 were stuck to server B. Of course, when server A was stopped, all 5 of those users were routed to B on their next request and they all got new sessions.
But with jbossha-httpsession deployed, if I open 10 browsers, they ALL end up opening on one of the servers -- say server A. Then if I stop server A, those users get routed correctly to server B and they have the same session that they had on server A.
So, the clustering failover is working great but my routine load balancing isn't utilizing both machines.
I can't find anything on 'setting load balance policy' in the clustering document. How do I set up round robin for this service?
You say that you are using an IIS DLL for your load-balancing. Then it is not JBoss but this DLL that you need to configure so that the load-balancing is done correctly.
1) For the Jakarta Tomcat redirector dll plugin, there is a simple piece of round robin load balancing that Tomcat must do. I think this redirector does it's round robin work by looking at a portion of the session cookie. To control this piece of the cookie, there is field called 'jvmRoute' that Tomcat places at the end of the session ID. The Tomcat configuration approach is to put the jvmRoute attribute into the Engine entry in the tomcat4-service.xml file like this:
Then, for the load balance redirector within the worker.properties file, you set up a worker with the same name like this:
Then, you can see in my example the session.getId() method returns a value like this:
Sticky load balancing works -- all requests for this session are forwarded to the worker called serverOne.
But when I use the jbossha-httpsession.sar, the session does NOT have the jvmRoute in it, instead the session looks like this with clustering turned on:
So, the IIS redirector does not know what to do because it does not find the .serverOne at the end of the session. It no longer does sticky load balancing.
2) I was somewhat incorrect in the way I reported it's behavior. What it actually does, is to round robin every request when clustering is turned on. I think this is not so bad as long as our application doesn't modify the session for every request. I might leave it alone and leave the session replication so it replicates immediately (the default I think). We'll load test and see if there is a performance hit.
3) Ideally, the jbossha-httpsession would continue to append the 'jvmRoute' of the 1st server hit to the end of the session id and I think sticky load balancing for the Tomcat redirector would be fixed.
I posted a detailed message but it did not make it to the forum (yet -- I still hope it does).
In summary, With Tomcat, there is a 'relationship' when using sticky load balancing between the Tomcat isapi_redirect.dll plugin, and the attribute called 'jvmRoute' set up in the Tomcat server configuration.
Call it 'proprietary load balancing'. You set up Tomcat with an Engine that has the 'jvmRoute' attribute in it (Jboss treats this as part of the 'config' Element for Tomcat). This jvmRoute name must match exactly the the name of a 'worker' you set up in your redirector.dll configuration.
When you do, each session id has the jvmRoute appended to it like this, where serverOne is my jvmRoute:
So, the isapi_redirect.dll load balancer just looks at the end of the sessionid and decides where to send the request. Simple.
I think this has been lost in the jbossha-httpsession.sar implementation. It might be Okay not to use sticky load balancing except that now I routinely get long exception traces in my console after a session expires. I think the server that is sharing the session does not know that the session has been removed. Here is the exception trace:
13:14:59,082 INFO [EmbeddedCatalinaServiceSX] javax.ejb.EJBException: Exception in setHttpSession: javax.ejb.FinderException: IlQ2aHC56M6P-F+KkFWOSA** does not exist
13:14:59,082 ERROR [LogInterceptor] TransactionRolledbackException, causedBy:
at $Proxy13.remove(Unknown Source)
at java.lang.reflect.Method.invoke(Native Method)
at $Proxy26.removeHttpSession(Unknown Source)
13:14:59,082 INFO [EmbeddedCatalinaServiceSX] Removing a session out of the clustered store failedjavax.ejb.EJBException: Exception in removeHttpSession: javax.transaction.TransactionRolledbackException: Load failed; CausedByException is: null; nested exception is:
javax.ejb.EJBException: Load failed; CausedByException is:
Any updates on this one? As far as i know, Jboss3.0.3_tomcat4.1.12 does NOT have the jvmRoute appended to session id. So i guess "stickiness" is not going to be there with session replication?
oops!! was using old config docs..jvmRoute is no longer in server.xml but in tomcat4-service.xml. Works perfectly fine in Jboss3.0.3_tomcat4.0.5..