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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
        [email protected]
        http://tp.its.yale.edu/mailman/listinfo/cas




-- 
Arnaud Lesueur

LinkedIn: http://www.linkedin.com/in/lesueur 
_______________________________________________
Yale CAS mailing list
[email protected]
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
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas

Reply via email to