[ mx4j-Feature Requests-1223039 ] Support for JDK 5.0? (possible memory leak in DOM/XML)

Feature Requests item #1223039, was opened at 2005-06-18 00:00
Message generated for change (Comment added) made by mstarkie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=450650&aid=1223039&group_id=47745

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tools: HTTP Adaptor
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kurt (kleucht)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support for JDK 5.0? (possible memory leak in DOM/XML)

Initial Comment:
This is not technically a Feature Request, nor is it 
technically a Bug, since you build MX4J using JDK 
1.4.2.  

I use MX4J on one of my projects basically only for it's 
HTTP Adaptor.  For reasons that aren't yet crystal clear 
to me, that project recently got upgraded from JDK 1.4.2 
to JDK 5.0.  Rather than have to switch back & forth 
between two separate compiler versions, I got rid of my 
old JAVA compiler and switched over to 5.0 completely.  
Aside from a few extra compiler warnings, everything 
seemed to be working okay after the switch.

But a week after delivering a new version of our product 
to our customer, we got a report of a very easily 
repeatable OutOfMemory error.  To make a long story 
short, it turns out that every time someone 
requests/receives the main HTML page from the MX4J 
HTTP Adaptor service (http://localhost:8080/), the Heap 
Usage of the app goes up and cannot be recovered ... 
not even via forced garbage collections.

As a minimal test, I just ran only the example 
HttpAdaptor code that is part of the MX4J code tree, and 
I was able to get the OutOfMemory failure by refreshing 
that example app about 100 times on my IE browser.  
You should be able to easily repeat this test by 
installing JDK 5.0 and then running your HttpAdaptor 
example.  Then I reinstalled the old JDK 1.4.2 and did 
the same test, but the failure never occurred ... not even 
after over 500 refreshes.  

I'm very far from being an expert in memory profiling and 
memory leak determination.  Some memory profiler 
software that I ran told me that something was holding 
on to references to DOM and/or XML Objects, but I 
couldn't get any more specific data than that from my 
tools.  I get the feeling that the tools were trying to tell 
me that com.sun.org.apache... type Classes were 
holding on to the references, but I'm not an expert in 
these memory profiling tools.  I know just enough to be 
dangerous.  

Have the MX4J developers ever tried MX4J under JDK 
5.0?  Have you seen the DOM/XML memory leak I am 
describing?  Is there something that can be "fixed" in 
the MX4J code to make this problem go away? Is this a 
SUN bug that someone much smarter than me ought to 
report to SUN?

Thanks for your time,
Kurt (from sunny Central Florida)

----------------------------------------------------------------------

Comment By: Michael Starkie (mstarkie)
Date: 2005-09-29 11:53

Message:
Logged In: YES 
user_id=889192

I am seeing the exact same problem when refreshing any page
of the HttpAdaptor on java 1.5.0_03.  Is there a fix for
this planned.  This is a serious problem since our
production applications are all switching over to java 1.5
and we use mx4j extensively.

----------------------------------------------------------------------

Comment By: Kurt (kleucht)
Date: 2005-06-21 12:26

Message:
Logged In: YES 
user_id=1110171

Additional info:

The JAVA 5.0 compiler gives me many unsafe type operation 
warnings for the MX4J CVS source that the JAVA 1.4 
compiler did not give.  How possible is it that these unsafe 
operations under JAVA 5.0 are the root cause of the memory 
leak that only occurs under JAVA 5.0?  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=450650&aid=1223039&group_id=47745


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl