[ 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.
> [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
