Leaking legacy code

Recently I have been working on an application that has been around for years and has lots of legacy stuff to maintain compatibility. The fact that we maintained Java 1.3 compatibility for a long time and very recently moved to Java 1.4 is a good indication.

When we moved to Java 1.4, it was due to the fact that our new JMS implementation required atleast Java 1.4. We reworked on bits of code to get it to work with the new JMS infrastructure, but never really thought about the Java 1.3 to Java 1.4 migration issues. Java 1.4 was a big clean up release and we should have been wise. However, fortunately or unfortunatley we did not face any issues all through our testing. But when the users started using the code in different situations like JNI or App servers, shit hit the fan.

One of the recent issues is interesting.

Some one wanted to run the code in JBoss - we had never built it with that in mind, but did not see any issues. So we said - go ahead, feel free. They did it and in testing, the server crashed with an out of memory exception!

This was the first ever reported memory leak, so we were concerned. I ran the code in Tomcat and Resin, the memory grew by 10MB in 12 hours and most of it was strings. We were running in debug mode and we use lots of string operations all over the place - so we were not suprised.

But when we ran in JBoss we saw a large number of JMX objects - BasicMBeanRegistry in the heap. We saw that they kept increasing in number with time.

We have a JMX interface to our code and it was written ages ago in Java 1.3. We did not know - and still dont know - how it affected the JBoss server. But as a test we switched off the JMX and today I am told it is running for more than 72 hours with under 90MB of memory.

So something in the way our JMX code was written is not going well with JBoss.
I am hoping we will not have to rewrite the JMX bit to adhere with Java 1.5 or higher.

Any ideas?