Mailing-List: contact issues-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
Date: Mon, 26 Dec 2016 10:29:58 +0000 (UTC)
From: "Vladimir Ozerov (JIRA)" <jira@apache.org>
To: issues@ignite.apache.org
Message-ID: <JIRA.13030071.1482402508000.594868.1482748198342@Atlassian.JIRA>
In-Reply-To: <JIRA.13030071.1482402508000@Atlassian.JIRA>
References: <JIRA.13030071.1482402508000@Atlassian.JIRA> <JIRA.13030071.1482402508035@arcas>
Subject: [jira] [Commented] (IGNITE-4476) GridIoManger must always process
 messages asynchronously
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 26 Dec 2016 10:30:00 -0000


    [ 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:

{code}
rwLock.readLock();
GridIoManger.send(...);
rwLock.readUnlock();
{code}

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
(v6.3.4#6332)