Close Your JMS Resources

In my work code, I had learned to very meticulously close all my JMS resources just to be sure they didn't hang around too long. In the first pass of some code, I had neglected this, but felt no repercussions.

I had not gotten around to applying the same wisdom to my personal blog code, and felt the wrath of the thread limit pretty quickly. It seems that in JBoss, every QueueSender, QueueSession, and QueueConnection spawns Read and Write Tasks with their own threads, and they just hang around with established connections (as verified with netstat). I'm sure the garbage collector would have cleaned these all up eventually, but they were coming too fast (one message per each HTTP request), and they quickly piled up.

I first saw the issue manifest itself as a java.lang.OutOfMemoryError due to its inability to spawn more than the 256 maximum threads as set by ulimit. A bit later, errors about "too many open files" start popping up as well. At first, I figured I may just need more threads, but as a classic resource leak goes, bumping up to 512 threads just made it take a little longer to hit the limit again.

Once I got my resources closing, I watched my thread count bounce around the 87-95. That's much better.

Filed Under: Java Work Computers Blog-Code