Marv, > From my experience, MemCacheTicketRegistry hardly ever throws exceptions, so > this would be odd, but there is some network IO going on under the hood, and > IO is a common cause of errors.
I think you have hit the nail on the head. I made the auditTrailContext.xml into basically a noop: <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:p="http://www.springframework.org/schema/p"; xmlns:aop="http://www.springframework.org/schema/aop"; xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd";> <description> Configuration file for the Inspektr package which handles auditing for Java applications. If enabled this should be modified to log audit and statistics information the same way your local applications do. The default is currently to log to the console which is good for debugging/testing purposes. </description> <aop:aspectj-autoproxy/> <bean id="auditablePrincipalResolver" class="org.jasig.cas.audit.spi.TicketOrCredentialPrincipalResolver"> <constructor-arg index="0" ref="ticketRegistry" /> </bean> </beans> And now I get this error: [#|2012-04-19T08:14:56.321-0600|WARNING|glassfish3.0.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=26;_ThreadName=http-thread-pool-9022-(1);|StandardWrapperValve [cas]: PWC1406: Servlet.service() for servlet cas threw exception net.spy.memcached.OperationTimeoutException: Timeout waiting for value at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:840) at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:855) at org.jasig.cas.ticket.registry.MemCacheTicketRegistry.getTicket(MemCacheTicketRegistry.java:121) My memcached server is running on Redhat while my CAS instance is running on a Solaris box so there is the network involved. I am brand new to memcached so it is running with default settings. I have been wondering what the preferred configuration of CAS and memcached is. Should CAS and memcached be on the same physical box or on separate boxes like my current configuration. Of course the end game is to have 2 or more load balanced CAS instances using repcache and memcached to share tickets and provide some level of HA. Thanks for helping with this. Obviously others have memcached working so there is something wrong in my environment. I am going to investigate the network timeout issue and try and fix that. IF that fails I will take up your offer to include the 3.5 code. Off to the memcached mail list for advice. Cheers, Bryan -----Original Message----- From: Marvin S. Addison [mailto:[email protected]] Sent: Thursday, April 19, 2012 7:51 AM To: [email protected] Subject: Re: [cas-user] Memcached Ticket Registry - Unresolved > <bean id="auditablePrincipalResolver" > class="org.jasig.cas.audit.spi.TicketOrCredentialPrincipalResolver"> > <constructor-arg index="0" ref="ticketRegistry" /> > </bean> I think this component is the culprit, though I can't say why exactly. Might be helpful to keep source in mind [1] for further discussion. Your description of the problem and the stack trace indicate that this is happening on the audit around CentralAuthenticationServiceImpl#destroyTicketGrantingTicket(). The following code block would be executed in both the success and failure cases: final Ticket ticket = this.ticketRegistry.getTicket((String) arg1); if (ticket instanceof ServiceTicket) { final ServiceTicket serviceTicket = (ServiceTicket) ticket; return serviceTicket.getGrantingTicket().getAuthentication().getPrincipal().getId(); } else if (ticket instanceof TicketGrantingTicket) { final TicketGrantingTicket tgt = (TicketGrantingTicket) ticket; return tgt.getAuthentication().getPrincipal().getId(); } Clearly if there were some problem looking up the TGT from the registry, it would throw in both cases since a principal is needed to log both a success and failure. From my experience, MemCacheTicketRegistry hardly ever throws exceptions, so this would be odd, but there is some network IO going on under the hood, and IO is a common cause of errors. We could use some more logging here to help diagnose these kinds of errors, but without source mods there's nothing further you can do to get more insight into the root cause. If you're feeling brave, you can check out my modified MemcachedTicketRegistry component that I'm working to get merged into master for 3.5: https://github.com/serac/cas/tree/memcached-ng As you can see [2], it has the logging you'd need to track down the specific error you're seeing. I can work with you on a ticketRegistry.xml if you're interested in trying it out. M [1] https://github.com/Jasig/cas/blob/master/cas-server-core/src/main/java/org/jasig/cas/audit/spi/TicketOrCredentialPrincipalResolver.java [2] https://github.com/serac/cas/blob/memcached-ng/cas-server-integration-memcached/src/main/java/org/jasig/cas/ticket/registry/MemcachedTicketRegistry.java -- 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] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
