You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Niklas Therning (JIRA)" <ji...@apache.org> on 2006/03/03 07:53:43 UTC
[jira] Reopened: (DIRMINA-169) Deadlock in ThreadPoolFilter
[ http://issues.apache.org/jira/browse/DIRMINA-169?page=all ]
Niklas Therning reopened DIRMINA-169:
-------------------------------------
The fix seems to have introduced a new problem. Even though I configured my ThreadPoolFilter's maximumPoolSize to be 10 I see over 600 worker threads when I do a thread dump. All threads are stuck in ThreadPoolFilter.destroy(). See the thread dump below. My app dies after some time probably because it's out of resources.
Here's a typical thread dump for one of the threads. All worker threads seem to be in the same state.
"Worker-623" prio=1 tid=0x8cae5260 nid=0x4f10 in Object.wait() [0x75ee5000..0x75ee5700]
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1103)
- locked <0x97457060> (a org.apache.mina.filter.ThreadPoolFilter$Worker)
at org.apache.mina.filter.ThreadPoolFilter.destroy(ThreadPoolFilter.java:209)
at org.apache.mina.common.support.IoFilterLifeCycleManager.callDestroyIfNecessary(IoFilterLifeCycleManager.java:214)
at org.apache.mina.common.support.AbstractIoFilterChain.deregister(AbstractIoFilterChain.java:363)
at org.apache.mina.common.support.AbstractIoFilterChain.remove(AbstractIoFilterChain.java:295)
- locked <0xb2578250> (a org.apache.mina.transport.socket.nio.support.SocketFilterChain)
at org.apache.mina.common.support.AbstractIoFilterChain.clear(AbstractIoFilterChain.java:304)
- locked <0xb2578250> (a org.apache.mina.transport.socket.nio.support.SocketFilterChain)
at org.apache.mina.common.support.AbstractIoFilterChain$2.sessionClosed(AbstractIoFilterChain.java:168)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionClosed(AbstractIoFilterChain.java:453)
at org.apache.mina.common.support.AbstractIoFilterChain.access$700(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.sessionClosed(AbstractIoFilterChain.java:742)
at org.apache.mina.filter.ThreadPoolFilter.processEvent(ThreadPoolFilter.java:687)
at org.apache.mina.filter.ThreadPoolFilter$Worker.processEvents(ThreadPoolFilter.java:421)
at org.apache.mina.filter.ThreadPoolFilter$Worker.run(ThreadPoolFilter.java:376)
Without the original synchronization in IoFilterLifeCycleManager it's possible that two threads call destroy() at the same time beacuse after thread A has decreased the ref counter and exited the synchronization block but before the call to destroy, another thread may have added the filter to a chain and then removed it again.
To honor the expected sequence of life cycle calls (init - destroy - init - destroy - etc) on a filter I think we will have to reintroduce the synchronization we had in IoFilterLifeCycleManager before the fix. We will have to come up with another fix for the original problem. Or maybe it will be possible to make some changes to AbstractIoFilterChain.
I hope this bug report made any sense! ;-)
> 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.
> IoThreadPool-3@547 prio=5, in group "main", status: WAIT
> blocks IoThreadPool-1@548
> blocks SocketAcceptor-0@4e9
> 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
> IoThreadPool-1@548 prio=5, in group "main", status: MONITOR
> waiting for IoThreadPool-3@547
> 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