Clustering CAS - why tomcat session replication?

[Scott Battaglia]

All of the information required by a flow is base64 encoded into a request
parameter using this method.  So the flow can be reconstructed on any
machine.

The default CAS instance doesn't story anything sensitive in the repository
so the default should be fine.  Your only concern could be older browsers
that improperly cache POST results.

-Scott

On Fri, Mar 7, 2008 at 3:06 PM, Andrew R Feller <afelle1 at lsu.edu> wrote:

>  Hey Scott,
>
>
>
> I did search the archives (
> http://www.nabble.com/CAS-Cluster-without-sticky-sessions-to7583161.html#a7584962)
> as we were interested in this issue, too.  After reading the documentation
> on the ClientContinuationFlowExecutionRepository, we think we can live with
> it once we customize it a little.  However, we have the concern whether one
> CAS server can continue the flow execution from another using this only.
>
>
>
> How much do you know about this?
>
>
>
> Thanks,
>
> Andy
>
>
>
> Andrew R Feller, Analyst
>
> University Information Systems
>
> 200 Fred Frey Building
>
> Louisiana State University <http://www.lsu.edu/>
>
> Baton Rouge, LA, 70803
>
> (225) 578-3737 (Office)
>
> (225) 578-6400 (Fax)
>
>
>  ------------------------------
>
> *From:* cas-bounces at tp.its.yale.edu [mailto:cas-bounces at tp.its.yale.edu] *On
> Behalf Of *Scott Battaglia
> *Sent:* Wednesday, March 05, 2008 8:31 AM
> *To:* Yale CAS mailing list
> *Subject:* Re: Clustering CAS - why tomcat session replication?
>
>
>
> If you search our archives a little bit, you will find some details on
> ways to reconfigure the Spring Web Flow such that it doesn't require
> sessions. If you do that you should ensure that your users use relatively
> recent browsers that won't have any issues with the back button resubmitting
> POSTs (such as the credentials you provided).
>
> -Scott
>
> On Wed, Mar 5, 2008 at 5:56 AM, Arnaud Lesueur <arnaud.lesueur at gmail.com>
> wrote:
>
> Step 2 is required for load balancing without a frontal load balancer
> which handles sticky sessions in front (the login webflow is using tomcat
> session)
>
> In case of a simple failover, this step is not mandatory.
>
> Regards,
>
> -Arnaud
>
>   On Wed, Mar 5, 2008 at 9:49 AM, Ina Müller <
> ina.mueller at zdv.uni-tuebingen.de> wrote:
>
>  Hello,
>
> we want to use CAS in a HA solution, so I had a look at
> http://www.ja-sig.org/wiki/display/CASUM/Clustering+CAS.
>
> It describes three steps:
> 1.- Ticket Uniqueness
> 2.- Tomcat Session Replication
> 3.- Ticket Cache Replication
>
> Steps 1 and 3 are clear. But for what scenario do I need step 2?
> What CAS specific stuff in session state has to be replicated?
> Isn't it enough to distribute the TGTs among the CAS servers to have a
> failover solution?
>
> Or lets restate the question:  if I omit step 2, what can go wrong in case
> of failover to another server?
>
> Thank you for your help, Ina
>
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
>
>
> --
> Arnaud Lesueur
>
> LinkedIn: http://www.linkedin.com/in/lesueur
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
>
>
> --
> -Scott Battaglia
> PGP Public Key Id: 0x383733AA
> 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
>
>


-- 
-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20080310/cfe338cd/attachment.html