[
https://issues.apache.org/jira/browse/DIRMINA-893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386375#comment-16386375
]
Jonathan Valliere commented on DIRMINA-893:
-------------------------------------------
That is interesting. because I probably would have said that it works correctly
and the developer should know the difference when writing the code. When you
call {{await()}} you know exactly whether it is or possibly is inside of an
{{IoProcessor}} thread. Basically, if you're in a {{IoFilter}} or
{{IoHandler}} then you are inside or should think you are in an {{IoProcessor}}.
The problem with the deadlock detection is that it gives false positives, as
shown above. If Code running in Server A calls {{close().await}} for a Channel
in Client A, it should allow the lock to block. This detection method actually
removes some functionality that other developers might be utilizing. I know
that I use cross-service awaits in my framework and tools. It allows me to
create proxy connections without callbacks.
That said, it would be very simple to add an {{IoProcessor.isCurrentThread}} to
see if the current thread is an {{IoProcessor}}
> '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
> Environment: XP, JDK 1.6
> Reporter: Carusyte
> Priority: Critical
> Labels: deadlock
> Fix For: 2.0.14
>
>
> 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 was sent by Atlassian JIRA
(v7.6.3#76005)
