Thanks for pointing this out!
I'm highlighting this information in my blog "How to Loadbalance GlassFish Cluster with Apache Loadbalancer" at
http://blogs.sun.com/jluehe/entry/supporting_apache_loadbalancer_with_glassfish
Under Configuration step 3, I now mention the following:
Make sure that the name of each worker equals the value of the
jvmRoute system property of the GlassFish instance to which the worker
connects. This convention makes it possible for an HTTP session to
remain sticky to the GlassFish instance on which the session was
created, or on which the session was last resumed.
and at the bottom of the blog, I've added this information:
As soon as the cluster instance to which an HTTP session has been
sticky has failed, the loadbalancer will route any subsequent requests
for the same HTTP session to a different instance. This instance will
be able to load and resume the requested session using the in-memory
session replication feature that has been available since GlassFish
V2. The in-memory session replication feature is enabled only for
those web applications that have been marked as distributable in their
web.xml deployment descriptor, and that have been deployed to the
cluster with the --availabilityenabled option of the asadmin deploy
command set to true (default is false).
I will also add this information to the GlassFish FAQ.
Jan
[Message sent by forum member 'jluehe' (jluehe)]
http://forums.java.net/jive/thread.jspa?messageID=273215