Lucas, Thank you and everyone else for the valuable input. I've narrowed down the problem. In the case of having to reauthenticate with the same CAS instance, I commented out the domainName property in my cas-servlet.xml file and this fixed it.
So it seems my problem of session replication is related to setting the domain. To address Andrew's point, there is not a space in <property name="cookieDomain" value=" scit.com" />. I tried to set a host entry in my /etc/Hosts file for setting up the scit.com domain however this doesn't appear to work. Even if I have my host entries like so, 192.168.1.111 scit.com CAS1 192.168.1.112 scit.com CAS2 only the first IP (*.111) will get resolved to scit.com unless the .111 fails then the domain name will resolve to .112. I'm beginning to think that I will have to implement a DNS server in order to get session replication to work. But what is the reason for requiring a domain name? Regards, David On 9/13/07, Lucas Rockwell <[EMAIL PROTECTED]> wrote: > > David, > At this point I think Andrew's may be right, especially considering you > have to re-authenticate on the same CAS instance. Can you check your cookies > in your browser to make sure you actually have one for CAS? Also, as Andrew > noted, it looks like you have a space in your cookieDomain property. Also, > does your server actually have a resolvable hostname in that domain? > > -lucas > > On Sep 13, 2007, at 10:01 AM, David Pham wrote: > > Lucas, > I believe my cluster is working and the CAS peers "know" of each other. > As you pointed out, the warning message > states that the operation will time out in 60 seconds if there is no > response from a peer. Immediately below that > message is an entry that states the cas session state was sent and > received in 279ms. Isn't this normal if session > replication is functioning? > > I just reloaded the CASes and here is a snippet from my CAS2 log. In bold > is the info for the cluster membership > and the info for sending/receiving the sesion state data. However my test > scenario still does not work. In fact, if I > authenticate with one CAS, I still have to reauthenticate with the same > CAS when trying to access my cassified application. > Something is out of place and I'm not sure what it is. > > Sep 13, 2007 11:39:36 AM > org.apache.catalina.cluster.tcp.SimpleTcpClustermemberAdded > INFO: Replication member added: > org.apache.catalina.cluster.mcast.McastMember > [tcp://192.168.1.111:4001,catalina,192.168.1.111,4001, alive=1162536] > Sep 13, 2007 11:39:38 AM > org.apache.catalina.cluster.mcast.McastServiceregisterMBean > INFO: membership mbean registered > (Catalina:type=ClusterMembership,host=localhost) > Sep 13, 2007 11:39:42 AM org.apache.catalina.cluster.session.DeltaManagerstart > INFO: Starting clustering manager...:/cas > Sep 13, 2007 11:39:42 AM org.apache.catalina.cluster.session.DeltaManagerstart > INFO: Register manager /cas to cluster element Host with name localhost > Sep 13, 2007 11:39:42 AM org.apache.catalina.cluster.session.DeltaManagerstart > INFO: Starting clustering manager at /cas > Sep 13, 2007 11:39:42 AM > org.apache.catalina.cluster.session.DeltaManagergetAllClusterSessions > WARNING: Manager [/cas], requesting session state from > org.apache.catalina.cluster.mcast.McastMember > [tcp://192.168.1.111:4001,catalina,192.168.1.111,4001, alive=1168204]. > This operation will timeout if no session state has been received within 60 > seconds. > Sep 13, 2007 11:39:42 AM > org.apache.catalina.cluster.session.DeltaManagerwaitForSendAllSessions > INFO: Manager [/cas]; session state send at 9/13/07 11:39 AM received in > 288 ms. > > > Regards, Davidd > > On 9/13/07, Lucas Rockwell < [EMAIL PROTECTED] > wrote: > > > > On Sep 13, 2007, at 7:38 AM, David Pham wrote: > > > > Hi Lucas, > > I'm actually using cas-server 3.0.7+ tomcat 5.5 too. I followed the > > cas clustering guide > > like the bible and I believe I have all components (e.g. ticket > > uniqueness, tomcat session replication, > > & jboss ticket registry) implemented correctly. Is there info in the > > catalina log that indicate > > my CASes are sharing session info? > > > > Here is an example of what I'm seeing in my logs when Tomcat loads up. > > I believe this indicates > > that the sessions are replicated, > > > > Sep 12, 2007 11:52:13 PM > > org.apache.catalina.cluster.session.DeltaManager getAllClusterSessions > > WARNING: Manager [/cas], requesting session state from > > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.112:4001,catalina, > > 192.168.1.112,4001, alive=100159]. This operation will timeout if no > > session state has been received within 60 seconds. > > Sep 12, 2007 11:52:13 PM > > org.apache.catalina.cluster.session.DeltaManager waitForSendAllSessions > > INFO: Manager [/cas]; session state send at 9/12/07 11:52 PM received in > > 279 ms. > > > > > > Session information is definitely not being shared, as can be seen from > > the WARNING line. > > > > You should see something like this: > > > > Sep 13, 2007 9:16:05 AM > > org.apache.catalina.cluster.tcp.SimpleTcpClustermemberAdded > > INFO: Replication member added: > > org.apache.catalina.cluster.mcast.McastMember[...] > > > > You can try adjusting your Mcast address. Try the default address that > > comes with the apache conf, which is 228.0.0.4, instead of the one on > > the cluster docs. If that works for you, I will change the clustering docs > > to the default address. > > > > -lucas > > > > > > Regards, David > > > > On 9/13/07, Lucas Rockwell <[EMAIL PROTECTED]> wrote: > > > > > > Hi David, > > > > > > (Keep in mind I have not does this with 3.1 yet, so this is for 3.0.7 > > > [it may be different for 3.1].) > > > > > > The session information about a logged in user is not replicated > > > using the JBossCacheTicketRegistry -- this is for the service ticket > > > registry. The problem you are experiencing is because the session > > > information from CAS1 is not being replicated to CAS2. Have you > > > implemented the Tomcat session replication part? If you are using > > > Tomcat, see the section labeled "Tomcat Session Replication" in the > > > clustering documentation. > > > > > > -lucas > > > > > > On Sep 12, 2007, at 8:59 PM, David Pham wrote: > > > > > > > Thanks for the quick response Scott, you were right, the errors > > > > were caused by a missing jar and not related to the CLASSPATH. > > > > > > > > So now that my cluster of 2 CASes have loaded and assuming I have > > > > session replication + cas clustering implemented > > > > properly I did a quick test that does not seem to work. Perhaps my > > > > understanding of how cas clustering is wrong because the cluster > > > > does not appear to be sharing the ticket registry. > > > > > > > > Test scenario: > > > > Load up CAS1 > > > > From client browser, access the casified application and get > > > > redirected to CAS1 login screen > > > > Authenticate and receive TGC from CAS1 > > > > > > > > Load up CAS2 > > > > Using the same browser window, access the casified app again > > > > the load balancer redirects to CAS2 login screen > > > > > > > > > > > > I should not have to reauthenticate with CAS2 if both CAS1 and 2 > > > > shared session data correct? However > > > > this is not the case as the client browser is not automatically > > > > redirected to the casified app. > > > > > > > > Regards, David > > > > > > > > > > > > On 9/12/07, Scott Battaglia <[EMAIL PROTECTED] > wrote: Its > > > > probably not a CLASSPATH variable issue as much as missing a > > > > required jar (in this case the JBossCache jar). If you are using > > > > the CAS 3.1 distribution, you should be able to declare the cas- > > > > server-integration-jboss (or whatever its called) as a dependency > > > > of the webapp project and when you package the webapp project it > > > > should include all of the necessary jars. > > > > > > > > -Scott > > > > > > > > On 9/12/07, David Pham < [EMAIL PROTECTED]> wrote: > > > > Hi All, > > > > Can anyone tell me what the CLASSPATH should be set to in order to > > > > implement jboss? Unfortunately I am getting NoClassDefFoundError > > > > exceptions > > > > despite following the instructions from this guide http://www.ja- > > > > sig.org/wiki/display/CASUM/Clustering+CAS. > > > > > > > > Here is an error example, > > > > > > > > The Spring ContextLoaderListener we wrap threw on > > > contextInitialized. > > > > But for our having caught this error, the web application context > > > > would not have initialized.> > > > > org.springframework.beans.factory.BeanCreationException : Error > > > > creating bean with name 'centralAuthenticationService' defined in > > > > ServletContext resource [/WEB-INF/applicationContext.xml]: Cannot > > > > resolve reference to bean 'ticketRegistry' while > > > > setting bean property 'ticketRegistry'; nested exception is > > > > org.springframework.beans.factory.BeanCreationException: Error > > > > creating bean with name 'ticketRegistry' defined in ServletContext > > > > resource [/WEB-INF/applicationContext.xml]: Instantiation of bean > > > > failed; nested exception is java.lang.NoClassDefFoundError: org/ > > > > jboss/cache/CacheException > > > > Caused by: > > > > org.springframework.beans.factory.BeanCreationException : Error > > > > creating bean with name 'ticketRegistry' defined in ServletContext > > > > resource [/WEB-INF/applicationContext.xml]: Instantiation of bean > > > > failed; nested exception is java.lang.NoClassDefFoundError : org/ > > > > jboss/cache/CacheException > > > > Caused by: > > > > java.lang.NoClassDefFoundError : org/jboss/cache/CacheException > > > > at java.lang.Class.getDeclaredConstructors0(Native Method) > > > > at java.lang.Class.privateGetDeclaredConstructors > > > > (Class.java:2357) > > > > at java.lang.Class.getConstructor0 (Class.java:2671) > > > > at java.lang.Class.getDeclaredConstructor(Class.java:1953) > > > > at org.springframework.beans.BeanUtils.instantiateClass > > > > (BeanUtils.java:60) > > > > at > > > > > > > org.springframework.beans.factory.support.SimpleInstantiationStrategy. > > > > instantiate(SimpleInstantiationStrategy.java :45) > > > > > > > > > > > > Regards, David > > > > > > > > _______________________________________________ > > > > Yale CAS mailing list > > > > [email protected] > > > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > > > > > > > > > > > > > > > > -- > > > > -Scott Battaglia > > > > > > > > LinkedIn: http://www.linkedin.com/in/scottbattaglia > > > > _______________________________________________ > > > > Yale CAS mailing list > > > > [email protected] > > > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > > > > > > > > _______________________________________________ > > > > Yale CAS mailing list > > > > [email protected] > > > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > > _______________________________________________ > > > Yale CAS mailing list > > > [email protected] > > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > > > _______________________________________________ > > Yale CAS mailing list > > [email protected] > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > > > > _______________________________________________ > > Yale CAS mailing list > > [email protected] > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > > > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
