They would be in ticketRegistry.xml, which is typically the place you have defined the instance of EhCacheTicketRegistry. Caches for each ticket type should have their own eviction policy.
From: Lazar, Michael E [mailto:[email protected]] Sent: Friday, June 07, 2013 11:41 AM To: [email protected] Subject: RE: [cas-user] OutOfMemoryError running CAS 3.5.2 via Jetty Hi, Thanks for the attention These settings in ticketExpirationPolicies.xml? We have the ST set at 60 seconds, and the TGT set at 1800 seconds, this is both values, time to live and time to kill. Correct? ${tgt.timeToKillInSeconds:1800} Your suggestions are welcome. Thanks, -Michael. From: Scott Battaglia [mailto:[email protected]] Sent: Thursday, June 06, 2013 7:00 PM To: [email protected] Subject: Re: [cas-user] OutOfMemoryError running CAS 3.5.2 via Jetty What is the expiration policy for the tickets in EhCache? Since most users don't actually log out and there is no registry cleaner, you'll need to make sure EhCache is cleaning itself up. On Thu, Jun 6, 2013 at 4:46 PM, Lazar, Michael E <[email protected]> wrote: Well it seems that these stack traces themselves are kind of all over the place so the hunch is based on the fact that ehcache was the last big change in architecture that we implemented. We are running under red hat 5.9 ala vmware, the servers are 4GB with -Xms and -Xms at 2048. One thought has been to increase the system's memory although those thoughts are also coupled with thoughts that the heap will just take longer to fill up. I will look into the yourkit solution -- I have been attempting at profiling with jvisualvm, but perhaps yourkit is a bit more helpful since I'm not sure exactly what we're looking for. Anything else that comes to mind will be helpful, thanks again. -Michael. -----Original Message----- From: Marvin S. Addison [mailto:[email protected]] Sent: Thursday, June 06, 2013 1:02 PM To: [email protected] Subject: Re: [cas-user] OutOfMemoryError running CAS 3.5.2 via Jetty > We are experiencing OutOfMemoryErrors with CAS running. This error > that I am including the trace of occurred within 8 hours of the > service startup which we are bouncing nightly at 4AM due to these memory issues. > > Our hunch is that it has to do with the EhCache module but this is > currently only speculation What evidence do you have for Ehcache? I don't see anything in the thread dump that suggests a problem there. In cases like these we typically enable the YourKit agent and capture periodic snapshots and then analyze them offline. If you've got a resource leak, that should help you find it. If you don't have access to YourKit, then the built-in JVM tool jmap can be used as a poor man's alternative. M -- 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 -- 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 -- 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
