So I have an application that simulates client load on our ejabberd nodes. Everything seemed to be running smoothly, but I noticed that, once I create all my users, connect them, log them in, and start having them send messages in chat rooms, the app slowly starts growing in heap size.
The funny thing is, I’m not caching anything myself, just listening for packets and messages, and logging them on the console.
However, the app grows and grows.
So I ran the app in JProfiler, and found that memory is mostly being used up by Strings/char[]'s in the org.xmlpull.mxp1.MXParser class, created by PacketReader.
The only thing I can think of is, there’s some huge backlog of messages from the server and the parser isn’t catching up.
Either that, or there’s something wrong with PacketReader or MXParser… I’m not sure though.
Take a look at the enclosed images from JProfiler - I’ve selected the main culprits in two snapshots, a few minutes apart.
Anybody ever seen this before?
- Tim
By the way, snapshot1 comes first, obviously - they’re displayed in the wrong order. 
Anyway, you’ll see the amount of memory used by the suspect classes grows quite a lot, and this is just during normal message sending (not very heavy load at all).
Also, I verified there’s no huge backlog of messages; I changed my test to only have 1 room and 3 users, sending messages about once every 10 seconds, and the memory still grew; more slowly, but still, and in the same place.
This MXParser/XmlPullParser code seems to be kind of old and crufty, or at least not really maintained. Is it possible it has a memory leak?
Okay, looking back into remarks here regarding earlier versions of Smack, I found this:
In which it says that nextMessage() (or pollMessage()) needs to be called within processPacket in order to remove the message from Smack’s internal queue.
I tried this, and it fixed my problem.
If there a reason this is still in the current version of Smack? I saw some notes that made it look like it had been fixed…?
