tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <mgai...@hotmail.com>
Subject RE: Fix your web application so it can cleanly un-deploy and re-deploy - how?
Date Thu, 07 Nov 2013 00:02:10 GMT
Springs over-use of CGLib for Interfaces is a memory consumer
Retask CGLib Proxy to JDKProxy to create your Impl classes for @Before advised methods

proxyTargetClass: false

Similarly using JavaAssist with Hibernate reduced memory footprint over CGLib significantly

 

http://docs.spring.io/spring/docs/3.0.0.M4/reference/html/ch08s05.html

http://what-when-how.com/Tutorial/SpringFramework3/SpringFramework300224.html

 

Dale: How did Mattias Jiderhamn's library help?


Martin  


  



> Subject: Fix your web application so it can cleanly un-deploy and re-deploy - how?
> Date: Thu, 7 Nov 2013 11:50:03 +1300
> From: Dale_Ogilvie@trimble.com
> To: users@tomcat.apache.org
> 
> Chris made the following good suggestion in another thread:
> 
> "Can I make a suggestion? Fix your web application so it can cleanly un-deploy and re-deploy
and then simply do a hot deployment?"
> 
> I've been down this track with our own Spring web apps and found it to be quite a deep
rabbit hole where a number of 3rd party libs are used. We get the issue where the webapp classloader
is not GC'ed due to classes in the libraries we use not being terminated cleanly. Which means
we get a big permgen memory leak when we redeploy the app. The "occasional tomcat restart"
workaround is effective, if nasty.
> 
> I did what Chris suggested for one of our apps and I think I got to 3rd party library
problem number FIVE (an oracle jdbc driver connection timer) before I gave up in disgust.
As I recall undisposed thread locals were a common theme. I used various strategies to resolve
the prior issues in things as simple as logging frameworks, JMS queuing libraries, underlying
http client code etc. Strategies such as:
> 
> 1. Specifically calling a low level library finalization routine in a context listener
or Spring lifecycle bean
> 2. Updating the 3rd party library to a later version which fixed the leak
> 3. Including Mattias Jiderhamn's active leak prevention library
> 
> I would so love it if Tomcat could just throw away the entire webapp memory footprint
on undeploy... Tomcat 7x memory leak protection wasn't good enough for our app a few months
ago.
> 
> Or failing that, if anyone can share successful strategies for "Fixing your web application
so it can cleanly un-deploy and re-deploy" please do.
> 
> Dale
> 
> Ref: http://wiki.apache.org/tomcat/MemoryLeakProtection
> Ref: https://github.com/mjiderhamn/classloader-leak-prevention
> 
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net] 
> Sent: Thursday, 7 November 2013 10:44 a.m.
> To: Tomcat Users List
> Subject: Re: how to bounce tomcat remote?
> 
> <snip>
> Can I make a suggestion? Fix your web application so it can cleanly un-deploy and re-deploy
and then simply do a hot deployment?
> <snip>
> 
> B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB��[��X��ܚX�KK[XZ[�\�\��][��X��ܚX�P�X�]
�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[�\�\��Z[�X�]
�\X�K�ܙ�B�
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message