[ http://issues.apache.org/jira/browse/DIRMINA-169?page=comments#action_12368702 ]
Trustin Lee commented on DIRMINA-169: ------------------------------------- Otherwise, we could do like this to avoid the deadlock. 1. acquire a lock for counts 2. edit count 3. acquire a lock for a filter 4. release a lock for counts 5. call destroy() 6. release a lock for a filter > 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
