The QFJ timer thread is shared by all sessions in all initiators and sessions. The ScheduledExecutorService can't be shutdown after an initiator or acceptor is stopped (unless I add some type of reference counting to it). Starting a new initiator or acceptor shouldn't create any more threads. Are you seeing multiple QFJ timer threads or just concerned that the thread still exists after you shut down your session connector?

The uncalled close method was a good catch. The ioSession is closed elsewhere so I'll remove that code, but I'm still investigating the reconnect job issues related to not calling close. Thanks.

I never see more than one QFJ Timer thread but it does not seem to be destroyed when I exit my application unless I manually terminate the VM. I was suspecting the QFJ Timer thread so I managed to override a few classes to gain control over it and shutting down the ScheduledExecutorService did the trick.

Maybe this only fixes my problem indirectly and the real issue lies somewhere else but I think it would be more elegant to gracefully shutdown the ScheduledExecutorService. I realize that the current implementation does not allow that but if there was one ScheduledExecutorService instance per initiator/acceptor instance it would be possible (in logoutAllSessions) and would not do any harm as I don't see much difference between 10 tasks on one thread and 5 tasks on 2 threads...

It sounds like your program's issue is caused by the QFJ thread not being a daemon thread. The QFTimerThreadFactory should set this flag so the thread doesn't keep the JVM from exiting. I'll make that change. Thanks for the report.

Funny because this was our first intuition and I did test the deamon thread fix but I must have done my testing wrong... Now it works.

I'll be waiting for an update, thanks for your responsiveness.

The fix for this problem for this problem has been added to the 1.0.x branch and the trunk.