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