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]<mailto:[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]<mailto:[email protected]>]
Sent: Thursday, June 06, 2013 1:02 PM
To: [email protected]<mailto:[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]<mailto:[email protected]> as:
[email protected]<mailto:[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]<mailto:[email protected]> as:
[email protected]<mailto:[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]<mailto:[email protected]> as:
[email protected]<mailto:[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
