There's no requirement to enable Tomcat session replication OR use sticky sessions. We, in fact, have neither enabled here (Rutgers).
The default configuration of the Spring Web Flow uses sessions to store state information (it means that a flow can't be re-used). If you reconfigure it to use request state information then you can disable any Tomcat sessions (in fact none would be created at all without you doing anything). If you choose to keep the default Spring Web Flow configuration you MUST either use sticky sessions OR replication Tomcat session information. You don't need to do both. Cheers, Scott On Thu, Sep 24, 2009 at 10:38 AM, Ryan Andreasen <[email protected]>wrote: > > We have CAS in a cluster of two. We are using a sticky session load > balance > and we are using a JPATicketRegistry. I see in the instructions to cluster > CAS it says that you must replicate session information between the tomcat > servers via multicast. I guess I don't understand why that is necessary if > the CAS servers use the database to store, retrieve, and validate tickets? > Why is it that getting a service ticket from server A will not be validated > on server B? Can anyone enlighten me as to why more is needed than the > JPATicketRegistry? > > Thanks! > -- > View this message in context: > http://www.nabble.com/CAS-Clustering-Problem-tp25573142p25573142.html > Sent from the CAS Users mailing list archive at Nabble.com. > > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
