[
https://issues.apache.org/jira/browse/IGNITE-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14713443#comment-14713443
]
Semen Boikov commented on IGNITE-1304:
--------------------------------------
Looks like it is caused by async operation implementation: next async operation
is started from the listener on previous operation. In the attached dump
listener for GridNearOptimisticTxPrepareFuture is called when topology read
lock is not released.
Also in most cases listener will be called from system pool thread, so attempt
to start new transaction from system poll thread may cause thread starvation.
> Async cache operations in IGFS may cause deadlock related to topology update
> ----------------------------------------------------------------------------
>
> Key: IGNITE-1304
> URL: https://issues.apache.org/jira/browse/IGNITE-1304
> Project: Ignite
> Issue Type: Bug
> Components: cache
> Affects Versions: ignite-1.4
> Reporter: Ivan Veselovsky
> Fix For: ignite-1.5
>
> Attachments: deadlock-1304.txt
>
>
> In an IGFS test we observe a deadlock situation related to cluster topology
> update (full thread dump is attached).
> The problem is that several threads are waiting for the topology update, at
> the same time holding the read lock of the topology version update:
> Thread #1:
>
> GridAffinityAssignmentCache.awaitTopologyVersion(GridAffinityAssignmentCache.java:450)
> ....
>
> GridNearOptimisticTxPrepareFuture.prepareOnTopology(GridNearOptimisticTxPrepareFuture.java:280)
> At the same time another thread, that wants to update the topology version,
> cannot do that because it needs the write lock of the topology update:
> Thread #2:
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.updateTopologyVersion(GridDhtPartitionTopologyImpl.java:190)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
