[ http://issues.apache.org/jira/browse/DIRMINA-169?page=comments#action_12368928 ]
Niklas Therning commented on DIRMINA-169: ----------------------------------------- Why don't we solve this problem like this: In ThreadPoolFilter we rename init() to startup() and destroy() to shutdown() so they won't be handled by IoFilterLifeCycleManager. Then we implement onPreAdd() which makes sure startup() is called the first time the filter is added to a chain (if not already started). We make all Worker threads daemon threads so that they will die when the JVM dies. I think this will work quite well no matter if your running inside a container like Spring or outside. In Spring you would use startup and shutdown as init-method and destroy-method. Outside a container the user will have to call startup/shutdown if needed, Otherwise the filter will startup the first time it's used and all workers will be killed once the JVM terminates. WDYT? > Deadlock in ThreadPoolFilter > ---------------------------- > > Key: DIRMINA-169 > URL: http://issues.apache.org/jira/browse/DIRMINA-169 > Project: Directory MINA > Type: Bug > Versions: 0.9 > Reporter: Rurik Krylov > Assignee: Trustin Lee > Fix For: 0.9.2 > > The dedlock occurs in case of simultaniously closing sessions. You can find > thread dumps below. > When 2 threads reach synchronized method callDestroyIfNecessary, reference > count is 0 already. So first thread tries to interrupt() second worker, but > it cannot be interrupted because it is lying on the synch block. > I'm not familar with this architecture, but from my point of of view > ThreadPoolFilter as singleton should not have too many synchronized methods. > In this particular case, synchronization of method callDestroyIfNecessary > should be narrowed to synchronisztion collection operations only. > filter.destroy() need not of synchronisation, and just it causes the deadlock. > [EMAIL PROTECTED] prio=5, in group "main", status: WAIT > blocks [EMAIL PROTECTED] > blocks [EMAIL PROTECTED] > wait():-1, Object.java > join():1103, Thread.java > destroy():209, ThreadPoolFilter.java > callDestroyIfNecessary():171, IoFilterLifeCycleManager.java > deregister():363, AbstractIoFilterChain.java > remove():295, AbstractIoFilterChain.java > clear():304, AbstractIoFilterChain.java > sessionClosed():168, AbstractIoFilterChain.java > callNextSessionClosed():453, AbstractIoFilterChain.java > access$700():52, AbstractIoFilterChain.java > sessionClosed():742, AbstractIoFilterChain.java > sessionClosed():165, ProtocolCodecFilter.java > callNextSessionClosed():453, AbstractIoFilterChain.java > access$700():52, AbstractIoFilterChain.java > sessionClosed():742, AbstractIoFilterChain.java > processEvent():687, ThreadPoolFilter.java > processEvents():421, ThreadPoolFilter.java > run():376, ThreadPoolFilter.java > [EMAIL PROTECTED] prio=5, in group "main", status: MONITOR > waiting for [EMAIL PROTECTED] > callDestroyIfNecessary():160, IoFilterLifeCycleManager.java > deregister():363, AbstractIoFilterChain.java > remove():295, AbstractIoFilterChain.java > clear():304, AbstractIoFilterChain.java > sessionClosed():168, AbstractIoFilterChain.java > callNextSessionClosed():453, AbstractIoFilterChain.java > access$700():52, AbstractIoFilterChain.java > sessionClosed():742, AbstractIoFilterChain.java > sessionClosed():165, ProtocolCodecFilter.java > callNextSessionClosed():453, AbstractIoFilterChain.java > access$700():52, AbstractIoFilterChain.java > sessionClosed():742, AbstractIoFilterChain.java > processEvent():687, ThreadPoolFilter.java > processEvents():421, ThreadPoolFilter.java > run():376, ThreadPoolFilter.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
