Yes, this would be an issue with dynamically created sessions. Have you considered using the SocketAcceptor instead of ThreadedSocketAcceptor?

Yea, certainly we could switch to the single threaded SocketAcceptor, for now. Longer term, however, the issue should probably be addressed. There are probably not too many people using the dynamic sessions, right?

The dynamic sessions were added primarily to support FIX simulators where you might not know the identity of counterparties before they connect. The issue you raised is valid. There are also other related issues. In general, the dynamic session support gives the ability to create new sessions on the fly but not the ability for those sessions (and associated resources) to be destroyed. For example, the sessions will not be garbage collected after logout and this could be considered a memory leak if there are a large number of dynamically created sessions.

We need functionality added to the dynamic session support to allow automatically destroying a session after logout (or maybe after it's been logged out for a specified period of time).

I'd like this to be reopened as threads still leak.
1. in ThreadPerSessionEventHandlingStrategy.stopDispatcherThreads the dispatchers.clear() is done before looping through the collection and so threads' stopDispatcher is never called
2. ThreadPerSessionEventHandlingStrategy.MessageDispatchingThread.run never terminates as this method repeatedly calls getNextMessage in a loop and getNextMessage calls messages.take which blocks indefinitely
3. also, stopDispatcherThreads should wait for threads to terminate before it returns so that everything gets cleaned up properly and in order

I've got a patch which fixes these by:
1. reordering statements in stopDispatcherThreads
2. using messages.poll which times out. Have set up a constant timeout of 10 seconds
3. waiting for threads to finish

What do people think about the timeout value? We could make this timeout configurable, or higher.

I can't upload the patch - is that because this issue is closed?

In reply to comment #5:
>
> I can't upload the patch - is that because this issue is closed?

How about creating a follow-up ticket? This ticket has been included into version 1.4.0
and re-opening it would make it difficult to track in which version this has been really corrected.

You could refer to this ticket, of course.

Follow up ticket created - http://www.quickfixj.org/jira/browse/QFJ-410