Dave, We are going ahead with sticky sessions behind an nginx proxy. Authentication at the CAS server is not RESTful due to (I believe) the Spring conversational state.
A shared session would be one way to accomplish that, but that seems like a rather complex solution to me. We've tested with sticky sessions and had satisfactory results. Thanks, Carl Waldbieser ITS Identity Management Lafayette College ----- Original Message ----- From: "Dave Steiner" <[email protected]> To: [email protected] Cc: "Aditi Deshmukh" <[email protected]> Sent: Monday, July 6, 2015 12:36:59 PM Subject: [cas-user] Problem with CAS Clustering and LT parameter We've been running a load-balanced CAS cluster of two nodes for a number of years now. The TicketRegistry is rep/memcached. Evidently our LT processing has been broken for quite some time. As we are trying to upgrade from 3.3.5 to 3.5.2 we noticed problems due to the LT parameter not being accessible across both CAS instances. In researching this, the Cas Clustering wiki page (https://wiki.jasig.org/display/CASUM/Clustering+CAS) suggests to use Tomcat Session Replication. We don't have any experience with Tomcat Session Replication. Is this definitely the way to go? How does this hold up under heavy loads? I'm assuming no one is recommending sticky sessions at the load balancer? Reasons? Also, I read some messages about putting the LT parameter into the TicketRegistry. Was that ever tried? Is it something that the CAS community recommends or not? Thanks in advance for all help and suggestions. -ds -- Dave Steiner [email protected] Identity Management, ESS ASB101; 848.445.5433 Rutgers University, Office of Information Technology -- 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
