[xmlblaster] memory leak with socket sessions

["Póka Balázs" <p.balazs at gmail.com>]

Hi there!

I've been noticing a very unusual thing lately, I had to restart our
xmlBlaster server every few days due to OutOfMemoryErrors. First I
thought it was because of my new SOCKET3 plugin I recently developed,
but the harder I thought the more I became convinced that it must be
something else.

It's been one day since the last restart and something's going on
already. I've managed to get a complete heap dump of the Java VM,
analyzed it using jhat, and found almost 100 MBs worth of byte[]
objects, all belonging to various SOCKET protocol connections which
all had zlib compression and SSL enabled (these two allocate a few
100k/client). Of course these sessions had already died a long time
ago due to some weird behaviour of one of the clients. The session
timeout was 10 minutes. All sessions have timed out properly according
to the log.

I'm running xmlBlaster 1.5.1, I didn't see any fixes which mention
memory leaks, so I suppose this has not been fixed yet.

I traced back the problem to the following field:

org.xmlBlaster.util.queue.QueuePluginManager.unprocessedEvents;
which is a HashMap, which in turn holds lots of Map.Entrys to
org.xmlBlaster.util.queue.ram.RamQueuePlugin objects.
The RamQueuePlugin.property field holds a
org.xmlBlaster.util.qos.storage.CbQueueProperty, which has a field
named addressArr.
This array then holds exactly one
org.xmlBlaster.util.qos.address.CallbackAddress.
That one has a field named callbackDriver ->
org.xmlBlaster.protocol.socket.CallbackSocketDriver
.handler -> org.xmlBlaster.protocol.socket.HandleClient
... and finally here are the streams and everything that is using most
of the memory.

I could sent the complete heap dump if one you developers needs it,
but I analyzed so that you don't have to; additionally there may be
sensitive information in there I may not want to give away. :)

regards,
Balázs Póka