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 Fri, 03 Mar 2006 23:50:40 GMT
    [ http://issues.apache.org/jira/browse/DIRMINA-169?page=comments#action_12368817 ] 

Niklas Therning commented on DIRMINA-169:
-----------------------------------------

I've had a look at this problem and I can't really see how the locking proposed could solve
the problem in itself. I realize now that it would take some changes to ThreadPoolFilter.destroy()
to resolve this issue.

Pete Royal also raised the question on the mailing list whether MINA should manage the life
cycle of filters or if that should be up to the user. Since 0.8.0 the filter chain handling
has changed quite a lot and the semantics of init()/destroy() are quite different from what
they used to be earlier. As it works right now init()/destroy() will be called all the time
on a filter as sessions are created and closed. Previously these life cycle methods were called
much less frequently.

I guess what I'm trying to say is that maybe we should consider removing the life cycle management
out of MINA all together (at least init()/destroy(), onPreAdd() and others might still be
useful). If a filter requires start/stop management it would be up to the user to manage that.
When using Spring this would of course be handled using the init-method/destroy-method features
of the ApplicationContext.

This change to MINA would also of course make the deadlock problem we're seeing here go away.

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