what is replicated in CAS clustering

[Andrew Petro]

Andrew, > client-side cookies are not replicated; > only Tomcat’s session data and ticket registries are. I'm not sure I understand the distinction. To the extent that CAS uses session cookies, these will be applicable across clustered CAS server instances in the case where a fronting load balancer makes them all appear to the browser to be the same hostname.  Session data will be as you say can be replicated across the cluster via Tomcat session replication.  What makes a jsessionid cookie interesting is that it keys into that server-side session data, which so long as it is exclusively composed of serializable [1] objects can be clustered across the Tomcats. The ticket granting cookie is valid by virtue of its bearing a valid "Ticket Granting Ticket".  Ticket granting tickets are stored in the ticket registry, and so clustering of the ticket registry accomplishes making a ticket granting cookie applicable across the cluster. User preference cookies (e.g. indicating the preference not to be transparently signed on) are not dependent on server-side state, so there's nothing to cluster.  I'm not sure what it would mean to replicate these cookies, but in any case they should work the same across clustered CAS nodes. Are we agreeing in all details and just saying the same thing differently, or have I missed something here? Andrew [1] sort of   2)  Within a cluster of CAS servers, how often does the ticket data get replicated? If one peer server goes offline then online, does the session data (as well as the ticket data) get replicated immediately or is there an interval at which this happens?   I am assuming there must be some handshaking process between the new server and existing servers thus allowing the new server to sync up with the cluster.   [Andrew R Feller] In the scenario of one node dropping from the cluster and reappearing, the JBoss Cache will re-establish its ticket registry whenever it successfully joins the cluster; there is no “waiting time”.  Cluster membership discovery can either be multicast or unicast depending upon your networking situation.  As far as frequency of ticket replication, that is a function of both JBoss Cache and Tomcat session replication.  However, I believe Claudio is mistaken in that client-side cookies are not replicated; only Tomcat’s session data and ticket registries are.       2)  Within a cluster of CAS servers, how often does the ticket data get replicated? If one peer server goes offline then online, does the session data (as well as the ticket data) get replicated immediately or is there an interval at which this happens?   I am assuming there must be some handshaking process between the new server and existing servers thus allowing the new server to sync up with the cluster.   The ticket replication is managed through two different mechanisms: client-side cookies are replicated using the cluster feature of the application server (tomcat), while the cas ticket registry is replicated among the cluster nodes using some other "pluggable" method. The document you read explains how to set up this through the jboss-cache libraries. In both cases, the syncronization method can be configured, but for cas cluster to work properly it should be set in syncronous mode, which means that data is replicated between the nodes each time it's modified.

_______________________________________________
Yale CAS mailing list
cas@tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas