Wednesday, October 20, 2004

GLUE 5.0.1 memory leak, and YourKit java profiler

I'm doing a project that involves a web services layer using WebMethods GLUE 5.0.1. We're using GLUE basically as an RMI replacement, since we've got to go through a firewall. The client side is a long-lived java process, and we're finding that it eventually runs out of memory. Finding leaks in java code is a pain in the ***, but I came across a nifty tool called YourKit that helps.

It tracks object allocations in your code. You can periodically take snapshots of the heap, and then compare the snapshots over time. It indicates how many instances have been created (and how much memory is used) of each class that exists in the heap. It also reports how many instances (and how many bytes) have been GCed for each class in the heap. Lastly, for a given instance, you can track the chain of references back to the GC root objects, which is really really nice for tracking down leaks.

The only thing wrong with it is that doesn't currently support the Mac OS/X java runtime. ARRRGH! They indicate that although they're using hooks that are supposed to be a standard part of the JVM, they bring down the OS/X java environment hard. They're hoping that things get better with the 1.5 JDK on Mac OS, but that doesn't help me much today.

Nevertheless, on Windows and Linux, and (in beta) on solaris, it rocks. Highly recommended.

Oh - and the leak in GLUE?

It looks so far that when you call Registry.bind(someUrl, someClass), and then invoke a method on the reference that returns a java.util.List, some part of the WSDL schema gets cached forever and is never cleaned up. This appears to be a known bug, and appears to be fixed in GLUE 5.0.2. I'm testing the maintenance release now...

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home