-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark,
On 8/27/12 6:07 PM, Mark Eggers wrote: > On 8/27/2012 1:24 PM, Christopher Schultz wrote: >> >> Hmm... that's ... not supposed to happen. The AppContext >> leak-prevention has been in Tomcat since back in 2009. Can you >> confirm that the JreMemoryLeakProtectionListener is actually >> being loaded? > > A heap dump (jvisualvm) on the following environments show one > instance of the class being loaded. That's good! > 1. Windows 7, JRE 1.7.0_05, Tomcat 6.0.35 2. Windows 7, JRE > 1.7.0_05, Tomcat 7.0.27 3. Windows 7, JRE 1.6.0_32, Tomcat 6.0.35 > 4. Windows 7, JRE 1.6.0_32, Tomcat 7.0.27 5. CentOS 6.3, JRE > 1.6.0_32, Tomcat 6.0.35, -Djava.awt.headless=true this is actually > running X Windows though 6. CentOS 5.8, JRE 1.6.0_32, Tomcat > 6.0.35, -Djava.awt.headless=true not running X Windows (dump via > jmap) > > Hmm - looking at Tomcat 6.0.35 on the CentOS 5.8 system, I see the > following when looking at the instance of > JreMemoryProtectionListener. > > appContextProtection (Z) : true awtThreadProtection (Z) : true appContextProtection=true is the default and awtThreadProtection=true is *not* the default. I would say that this is the proper configuration for what you are trying to solve. In that case, can you check the ClassLoader used for the AppContext and AWT threads? > And I do have the attribute set to manage the AWT thread (at least > on the Tomcat I dumped). > > On the Windows (Tomcat 6.0.35, JRE 1.6.0_32), I see the following: > > appContextProtection (Z) : true awtThreadProtection (Z) : false > classesToInitialize (L) : <null> driverManagerProtection (Z) : > true gcDaemonProtection (Z) : true ldapPoolProtection (Z) : true > securityLoginConfigurationProtection (Z) : true > securityPolicyProtection (Z) : true tokenPollerProtection (Z) : > true urlCacheProtection (Z) : true xmlParsingProtection (Z) : true > > which is what I expect from server.xml. So the server.xml has awtThreadProtection=false (or just uses the default)? > Commenting out the listener (actually it doesn't matter either way > since I'm running in a windowed environment) and adding the AWT > Event thread protection produces on Windows: > > appContextProtection (Z) : true awtThreadProtection (Z) : true > classesToInitialize (L) : <null> driverManagerProtection (Z) : > true gcDaemonProtection (Z) : true ldapPoolProtection (Z) : true > securityLoginConfigurationProtection (Z) : true > securityPolicyProtection (Z) : true tokenPollerProtection (Z) : > true urlCacheProtection (Z) : true xmlParsingProtection (Z) : true If you comment-out the listener, they why is the class loaded at all? Are you sure everything in your environment is sane? > And I still see the exact same permgen memory leak upon unloading > the application. > > The problem looks to be in an internal use of MediaTracker. I > suspect that the library uses this to speed image recovery should > there be repeated calls. IIRC MediaTracker is a concurrent component that loads stuff (like images) in the background and sends update-events to interested components. Perhaps there is yet another thread that needs to be managed on top of the AWT thread. Can you take a thread dump and possibly indicate the ClassLoader for each thread? > Unfortunately, these images are dynamically generated, so any use > of MediaTracker is pretty worthless in this use case. I've found that use of the MediaTracker is entirely worthless except when using GUIs that need to display images within components (like buttons, etc.). Anyone using MediaTracker in a client-side library is making a mistake (that is, your 3rd-party library is either not targeted towards a server-side application, or the devs don't know what they are doing). > There's a way to purge the library caches, and I've experimented > with that as well. Unfortunately, it doesn't unregister the images > it stored in the MediaTracker. In short, flushing the library's > cache in this use case does not address the problem. Fantastic. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA84XEACgkQ9CaO5/Lv0PDHoACeLrDXPbfkqeLBoaIy8My8gmGA ZgwAniWtkEP3WSk47Mxjg36flndbbJ0U =Abus -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
