+1, good idea, sounds easy

On 3/5/06, peter royal (JIRA) <[EMAIL PROTECTED]> wrote:
>     [ 
> http://issues.apache.org/jira/browse/DIRMINA-169?page=comments#action_12368935
>  ]
>
> peter royal commented on DIRMINA-169:
> -------------------------------------
>
> +1 to Niklas idea about init/destroy -> startup/shutdown. i'd prefer 'start' 
> and 'stop' as the method names though.
>
> > 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
>
>

Reply via email to