[ http://issues.apache.org/jira/browse/DIRMINA-169?page=comments#action_12368844 ]
Niklas Therning commented on DIRMINA-169: ----------------------------------------- I got a bit carried away last night after Pete posted his thoughts on letting go of the life cycle management stuff. Anyway, I think your locking strategy will work. I'll give it a try and see what I can come up with. However, I think the discussion which was initiated by Pete is very important. If MINA wasn't handling init/destroy problems like this would go away naturally. And in our app we have quite a lot of connections coming in but they are short lived which means that the number of active sessions are 1 most of the time. This means that init/destroy will be called all of the time which I don't think is really the intention. This was different in previous versions of MINA when a small number of filter chains were shared between sessions so we might have to think this through. > 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
