Mark Thomas wrote:
>Your rant would be better aimed at the developers of the third party
libraries and JVMs that create the problems in the first place rather
than at the community that has worked hard to:
>- prevent them causing an issue in the first place [1], [2]
>- cleans up the mess they leav
On 21/03/2012 00:40, Dale Ogilvie wrote:
> In our webapps running on Tomcat 7 we have seen quite a number of
> classloader memory leaks. The end result is that after a number of
> application reloads and redeploys, we run out of permanent generation
> memory and Tomcat stops responding. We can see
On 21/03/2012 08:25, Leon Rosenberg wrote:
> On Wed, Mar 21, 2012 at 7:52 AM, Pid * wrote:
>> On 21 Mar 2012, at 02:41, Dale Ogilvie wrote:
>
>>
>>> When the application is unloaded by Tomcat, it
>>> should go away completely, regardless of (for example) unstopped threads
>>> in library foo.
>>
On Wed, Mar 21, 2012 at 7:52 AM, Pid * wrote:
> On 21 Mar 2012, at 02:41, Dale Ogilvie wrote:
>
>> When the application is unloaded by Tomcat, it
>> should go away completely, regardless of (for example) unstopped threads
>> in library foo.
>
> There is an aggressive thread killer option but it
On 21 Mar 2012, at 02:41, Dale Ogilvie wrote:
> In our webapps running on Tomcat 7 we have seen quite a number of
> classloader memory leaks. The end result is that after a number of
> application reloads and redeploys, we run out of permanent generation
> memory and Tomcat stops responding. We c
In our webapps running on Tomcat 7 we have seen quite a number of
classloader memory leaks. The end result is that after a number of
application reloads and redeploys, we run out of permanent generation
memory and Tomcat stops responding. We can see the evidence of this sort
of issue thanks to the
