tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: getRealPath returns null
Date Tue, 28 Aug 2012 15:19:13 GMT
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message