Thanks for the info.
I'm unclear about one item, however. You said
It's easier to simply deploy CAS in a Tomcat instance by
itself and restart the container as part of redeployment.
What do you mean by "deploy CAS in a Tomcat instance by itself"? What
does "by itself" mean?
--
Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/
On Thu, Jul 25, 2013 at 8:35 AM, Marvin S. Addison
<[email protected]> wrote:
>> Has anyone else seen such behavior?
>
>
> See it all the time. The root cause is dangling object references that pin
> the parent class loader and all the classes it loaded on startup. For
> non-trivial apps that is typically a lot of data. Since class definitions
> are placed in the PermGen slot of the JVM, it quickly fills up on repeated
> Webapp deploys. Increasing PermGen size only delays the inevitable.
>
> This comes up occasionally but it's genuinely a difficult problem. It is
> feasible to track down all the places where we might leak resources (e.g.
> thread locals) in CAS, but the problem is fairly intractable when
> considering the myriad libraries on which CAS depends. The Spring Framework
> and Hibernate are two huge dependencies; there are many others. It's easier
> to simply deploy CAS in a Tomcat instance by itself and restart the
> container as part of redeployment. I believe most CAS deployers do this; we
> certainly do.
>
>
> 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
