QuickFIX/J and Odd Memory Leaks

This is more a case of posting here to remind myself, but maybe it will help someone out. I just ran into a case where QuickFIX/J seemed to be stacking up endless messages in a LinkedHashMap object (messageQueue) in SessionState.java (discovered using a heap dump and the helpful Memory Analysis Tool from Eclipse) and spent a few hours banging my head on the wall trying to figure out why. After I bothered to read the QFJ code, I understood why, but it’s non-obvious.

Essentially, QFJ’s Session class parses each incoming message, and then attempts to parse any “queued” messages from the aforementioned LinkedHashMap before doing it all again. The contents of the LinkedHashMap (in my case, built up to 500+ megabytes before bringing the JVM to flaming ruin) are only messages that result from a “sequence number too high” error. So if your QFJ application throws, for example, a repeated NPE while handling FIX messages, in certain cases this can trigger a “sequence number too high” problem and will result in FIX messages stacking up in that QFJ-side queue.

I’m not sure if this is really a bug in QFJ or not — I should have checked the QFJ event log sooner, and I might have solved this without noticing the pileup. I suspect that’s why there isn’t a lot of information to be easily found online about the issue – other people just debug their applications correctly.;) That said, it’s non-obvious to me that anything I do in my QFJ application should result in some map inside QFJ’s core classes growing out of control. Hence, noted for myself and anyone else who may care/be curious.:)