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
