We moved a FIX gateway server built on quickfixj into production a few
days ago, and it quickly became quite clear that the java program
leaked menory somehow, and so did the mysql server. Both servers grew
to about 2GB each in a few hours. After that, we had to restart the
processes because of performance problems.

Anyway, I traced the problem to the JdbcStore class, which allocates a
new statement for each call. The statement is never closed.
Depending on the Jdbc driver, these statements might or might not be
garbage collected, but in our case they were at least not.

After patching the code everything seems to run really well and fast.

Anyway, I'm a bit reluctant to post a patch since the one I made is so
ugly... It seems that someone started work on caching prepared
statements in the JdbcStore class (using the statementCache member),
but since it is not finished, it results in the leak. The JdbcLog
class does not have this problem.

At first glance it seems very easy to make the cache work (the only
missing statement is one that actually adds the statement to the
cache). It seems to me that thread safety needs to be taken into
account, which might not be trivial. Maybe that's why the cache
mechanism was never finished?

Btw, my current patch just adds a close() call to a number of places.

Staffan