what is replicated in CAS clustering
Andrew R Feller
afelle1 at lsu.edu
Fri Sep 7 13:00:21 EDT 2007
David,
BerkeleyDb is its own beast: http://en.wikipedia.org/wiki/Berkeley_DB
Andrew R Feller, Analyst
Subversion Administrator
University Information Systems
Louisiana State University
afelle1 at lsu.edu
(office) 225.578.3737
________________________________
From: cas-bounces at tp.its.yale.edu [mailto:cas-bounces at tp.its.yale.edu]
On Behalf Of David Pham
Sent: Friday, September 07, 2007 10:34 AM
To: Yale CAS mailing list
Subject: Re: what is replicated in CAS clustering
Scott,
Thanks for the reference to BerkleyDb. Off the top of your head, do you
know if the persistence is implemented using a RDBMS such as mySQL or a
flat file?
Regards, David
On 9/7/07, Scott Battaglia <scott.battaglia at gmail.com> wrote:
David,
You'd have to implement a Ticket Registry that persists them (we have a
BerkleyDb example in CAS). However, if you are using the distributed
JBoss Cache implementation, if you take one down and bring it back up I
would think (in theory) that it should receive all of the information.
If you take them all down at the same time, well.... :-)
-Scott
On 9/7/07, David Pham < dpham6 at gmail.com <mailto:dpham6 at gmail.com> >
wrote:
Thanks for the input Scott.
Additionally this question is somewhat related to session replication.
Is there also a way to set up persistent storage for the ticket granting
cookies? My understanding is that CAS stores the tickets in-memory but
with the experiment I'm doing, I will be taking CASes online and offline
at timed intervals and it would be ideal if I can somehow dump the
ticket registry to a database or a flatfile.
Regards, David
On 9/6/07, Scott Battaglia < scott.battaglia at gmail.com
<mailto:scott.battaglia at gmail.com> > wrote:
On 9/6/07, David Pham <dpham6 at gmail.com> wrote:
Scott,
In regards to replicating the client-side cookies I
understand that in order to make the cookie visible to all the CASes in
the cluster, we have to configure them to be on the same domain by
modifying the cookieDomain property. But what if our CASes are not in a
domain? In other words, each of my CAS is housed on its own host
computer and the domain is simply " localhost.localdomain" where the
hosts know of each other because they belong to the same private
network.
There should be some domain that points to both of those servers (how
else would your users access CAS as a single "service"?). That domain
should be what is set.
-Scott
Regards, David
On 8/29/07, Scott Battaglia <scott.battaglia at gmail.com> wrote:
Guys--
Depending on how you configure CAS, various items can be
replicated.
If you use a Distributed Ticket Registry, such as JBossCache (or
any custom one such as a JDBC), the Ticket Granting Tickets and Service
Tickets are replicated amongst the CAS servers. Their updated state
should also be replicated amongst CAS servers the instant (well
conceptually, the instant) they are modified.
If you've configured Tomcat (or your container) for session
replication, then the Tomcat sessions should be replicated. Tomcat
sessions only contain information relevant to the initial Spring Web
Flow login process (if you don't replicate Tomcat sessions then you need
to use sticky sessions or modify the Web Flow configuration to use
client side storage).
Client Side information is still maintained within the browser.
The cookie that holds the Ticket Granting Ticket ID should be sent to
either CAS server, assuming the domain/path information is specified
correctly (and since the registry is duplicated, all tickets should be
accessible). The same thing can be said for the "warn" cookie.
-Scott
On 8/29/07, Andrew R Feller < afelle1 at lsu.edu
<mailto:afelle1 at lsu.edu> > wrote:
Andrew,
Yes, I believe we are saying the same thing. The
distinction I was trying to bring up was client-side cookies stored in
your web browser versus server-side sessions. There is no way, I am
aware of, to replicate client-side cookies on a user's web browser. I
know the ticket granting ticket's cookie should be scoped a specific
domain/subdomain that only the CAS servers can see and thus available to
all of them.
Thanks,
Andy
Andrew R Feller, Analyst
Subversion Administrator
University Information Systems
Louisiana State University
afelle1 at lsu.edu
(office) 225.578.3737
________________________________
From: cas-bounces at tp.its.yale.edu
[mailto:cas-bounces at tp.its.yale.edu] On Behalf Of Andrew Petro
Sent: Tuesday, August 28, 2007 6:47 PM
To: Yale CAS mailing list
Subject: what is replicated in CAS clustering
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 at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas
--
-Scott Battaglia
LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________
Yale CAS mailing list
cas at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas
_______________________________________________
Yale CAS mailing list
cas at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas
--
-Scott Battaglia
LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________
Yale CAS mailing list
cas at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas
_______________________________________________
Yale CAS mailing list
cas at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas
--
-Scott Battaglia
LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________
Yale CAS mailing list
cas at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20070907/ecf0f036/attachment.html
More information about the cas
mailing list