ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ozerov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-4476) GridIoManger must always process messages asynchronously
Date Mon, 26 Dec 2016 10:29:58 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15778085#comment-15778085

Vladimir Ozerov commented on IGNITE-4476:

Personally I observed in GridGain plugin. Yes, it is proprietary code, but it demonstrated
the problem nicely. In short, we have the following pseudocode there:


We expect that this code piece will be executed quickly, and read lock will be released. However,
this piece of code is executed synchronously, what leads to very dready deadlock on {{readLock
<- writeLock <- readLock}} chain.

That is, we have hidden deadlocks in a product due to this optimization. I am not talking
about striped pool, it is out of a question here. My point is that if message should be executed
in pool X by design, it should be executed in this pool irrespectively of whether this is
local or remote message.

> GridIoManger must always process messages asynchronously
> --------------------------------------------------------
>                 Key: IGNITE-4476
>                 URL: https://issues.apache.org/jira/browse/IGNITE-4476
>             Project: Ignite
>          Issue Type: Task
>          Components: general
>    Affects Versions: 1.8
>            Reporter: Vladimir Ozerov
>             Fix For: 2.0
> *Problem*
> If message is to be sent to remote node, we just send it (surprise :-)). But if message
is to be sent to local node, we have a strange "optimization" - we process it synchronously
in the same thread. 
> This is wrong as it easily leads to all kind of weird starvations and deadlocks.
> *Solution*
> Never ever process messages synchronously. For local node we should put message runnable
into appropriate thread pool and exit.

This message was sent by Atlassian JIRA

View raw message