mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niklas Therning (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRMINA-169) Deadlock in ThreadPoolFilter
Date Sun, 05 Mar 2006 10:11:41 GMT
    [ 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.
> 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


Mime
View raw message