Scott, thanks for the reply. That actually confirms my understanding of how things work, and and makes sense. I'll give that a try then in the next couple of days...
Johan ----- Original Message ----- From: Scott Battaglia To: [email protected] Sent: Tuesday, March 24, 2009 12:54 PM Subject: Re: [cas-user] CAS Heap exception You still need to back the CAS Ticket Registry with a high availability backend such as Memcached or JBoss, etc. What Andrew is suggesting is that the front-end, meaning the Spring Web Flow can utilize client-side data storage instead of server side data storage (i.e. sessions) which eliminates the need to replicate Tomcat sessions. Long term CAS ticket information is NEVER stored in Http Sessions. Only the short term Web Flow related items are, if configured to do so. -Scott On Tue, Mar 24, 2009 at 3:49 PM, Johan Reinalda <[email protected]> wrote: I am also interested in this method of HA. Is the modification really as simple as Andrew describes in his post ? If all is passed via forms (my very limited understanding of it after glancing at the spring docs), how are TGT tickets "remembered" or passed to another server? Eg. if the primary fails after user authentication, and a user tries to access a new CAS-enabled services, how does the failover know about the Principal data that goes with the TGT it gets handed via the cookie ? I, too, am struggling with the tomcat-session-cookie based HA, and if this is truly that much simpler, I would like very much to have some more explanation of the Spring flow client HA method... Thanks, Johan ----- Original Message ----- From: "Adam Rybicki" <[email protected]> To: <[email protected]> Sent: Tuesday, March 24, 2009 11:47 AM Subject: Re: [cas-user] CAS Heap exception David, It is worrisome to hear that Tomcat session replication may be causing the OutOfMemoryError. Well, it may not be the cause, but1 GB is a lot of memory for CAS. Did you have a chance to try what Andrew suggested? His modification eliminates the need for Tomcat session replication, and if that was the cause of a memory leak, you would have effectively eliminated it. Are you using the version of Tomcat that comes with RHEL 5.3 or a separate version directly from Apache? I ask because the version distributed with RHEL looks to be heavily modified from the original distribution and fairly old. Adam David Ruwoldt wrote: Dear All, Sorry for all the questions. CAS 3.3.1, RHEL 5.3, Tomcat 5 We have seen the following exception twice in the last 18 hours. Exception in thread "org.apache.catalina.cluster.tcp.TcpReplicationThread[4]" java.lang.OutOfMemoryError: Java heap space The node becomes unresponsive and the cluster goes down because the load gets transferred to the other node which then runs out of memory. We have only been running with 1 GB of ram on the VM's. We are changing this to 4 GB of ram tonight. We are also setting the tomcat param -Xmx to 3 GB. Is there anything else we should be looking at. I have downloaded a heap of tomcat tuning doco but have not had time to read it as yet. Yours sincerely David Ruwoldt -- 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] 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
