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_ogil...@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:ch...@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�
