Ok, the problem was that the jBPM installation I used did not close connections after each and every JMS message send it did. In fact, jBPM JMS subsystem keeps one single Connection and Session for the whole life of the server application. The JMS specification says that : anonymous wrote : A JMS Connection is a client'™s active connection to its JMS provider. It will | typically allocate provider resources outside the Java virtual machine. | | Connection objects support concurrent use. | and anonymous wrote : A JMS Session is a single-threaded context for producing and consuming | messages. Although it may allocate provider resources outside the Java virtual | machine, it is considered a lightweight JMS object. If I read between the lines correctly, this should mean that it is acceptable to keep a costly Connection for a long time while it is not really acceptable to keep a "lightweight" Session for a long time. If I close Sessions but not Connections, the thread blocking still persists. So I modified the code to close both and the thread blocking no longer appears. Is it normal that if a Connection is hold for a long time, a thread leak, eventually followed by OutOfMemory, occur ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129452#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...