mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DIRMINA-893) 'fake deadlock' causes IoFuture.await() to malfunction
Date Mon, 09 Jul 2012 16:15:35 GMT

    [ 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

        

Mime
View raw message