[jira] [Commented] (DIRMINA-893) 'fake deadlock' causes IoFuture.await() to malfunction

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DIRMINA-893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409599#comment-13409599 ] 

Emmanuel Lecharny commented on DIRMINA-893:
-------------------------------------------

This is a real problem. Both the Acceptor and the Connector depend on NioProcessor to process the outgoing and ingoing messages, thus the deadlock check will exit the loop in both cases. What you can do is to use the await( timeout ) with a loop around to replace the call to await(). Another option would be to catch the exception you get and to retry.

Those are workarounds, dirty ones, but keep in mind that this deadlock check is there to protect the server and client from a dead connection, not waiting forever, locking some resources.
                
> 'fake deadlock' causes IoFuture.await() to malfunction
> ------------------------------------------------------
>
>                 Key: DIRMINA-893
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-893
>             Project: MINA
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0.2, 2.0.4
>         Environment: XP, JDK 1.6
>            Reporter: Carusyte
>            Priority: Critical
>              Labels: deadlock
>
> I am using a NioSocketConnector inside a NioSocketAcceptor (like a message broker / proxy app), and I need to use the connector in synchronous mode therefore I have to call IoFuture.await() or the method alike.
> The problem is, as I look into the source code, when it comes to ConnectionFuture.await(), if the connection is not ready, DefaultIoFuture.checkDeadLock() will be called, iterating through the stack trace of current thread, checking to see if AbstractPollingIoProcessor is involved in the trace, and if so, throw a dead lock exception. The point is, IMHO, this AbstractPollingIoProcessor is created by the NioSocketAcceptor, not by the NioSocketConnector, and thus shouldn't be interpreted as a dead lock threat.
> How can I work around this issue?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira