It appears that there can be two root causes of this behaviour. The client, as has been discussed or...your network configuration.
As I mentioned, we run tomcat clustered to replicate sessions and are backed by a JbossTreeCache, all of which runs behind an F5 BigIp load balancer. The configuration had been running rock solid for the past year, through cas upgrades, hardware upgrades etc...Then it broke. After poking around our network I finally figured out what caused our CAS servers to stop sharing tickets. When you configure clustered tomcat and the JbossTreeCache, the out of the box multicast address starts with 228.x.x.x which is technically in the range of valid multicast ip however..the network operations group moved our servers on to a different VLAN that was configured to use 224.x.x.x well when we re-configured the CAS servers to use 224..everything worked. Moral of the story: If you are running clustered tomcat behind a load balancer and using a replicated cache to store service tickets and run into this...check the multicast. I found an interesting set of tools for testing multi-cast while researching this stuff: http://www.29west.com/docs/TestNet/testnet.html I installed those tools on the 2 servers in /root/mtools/. You can listen for multi-cast traffic w/ a few commandline switches. Pretty useful. You might also want to consider writing a small servlet that will add an object to your cache and then remove it..you can test the cache by pushing on one server and pulling on the other. Just my .02 worth. Dean -- View this message in context: http://jasig.275507.n4.nabble.com/Re-CAS-infinite-redirect-loop-tp584495p3089433.html Sent from the CAS Users mailing list archive at Nabble.com. -- 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
