[
https://issues.apache.org/jira/browse/GEODE-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189578#comment-17189578
]
ASF subversion and git services commented on GEODE-8475:
--------------------------------------------------------
Commit b62e033af490d6f1e8f40621ff084b099f5b52e8 in geode's branch
refs/heads/develop from Xiaojian Zhou
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b62e033 ]
GEODE-8475: Resolve a potential dead lock in ParallelGatewaySenderQueue (#5492)
Co-authored-by: Darrel Schneider <[email protected]>
> Resolve a potential dead lock in ParallelGatewaySenderQueue
> ------------------------------------------------------------
>
> Key: GEODE-8475
> URL: https://issues.apache.org/jira/browse/GEODE-8475
> Project: Geode
> Issue Type: Improvement
> Reporter: Xiaojian Zhou
> Assignee: Xiaojian Zhou
> Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> When brq is created but encountered a failed GII, enqueue to it could have a
> potential deadlock:
> Thread-1:
> ParallelGatewaySenderQueue.put() will get a
> brq.getInitializationLock().readLock().lock() (lock-A’s read lock). Then
> during the put operation, it will try to call lockWhenRegionIsInitializing()
> to get failedInitialImageLock.readLock().lock (lock-B’s read lock)
> Thread-2:
> PRDS.createBucketRegion() will trigger GII but failed. So it will call
> cleanUpAfterFailedGII(), where it will call lockFailedInitialImageWriteLock
> () to get lock-B’s write lock first. Then call
> BucketRegionQueue.clearEntries().
> It will call getInitializationLock().writeLock().lock() (lock-A’s write lock).
> To fix it, we need to let thread-1 to get failedInitialImageLock.readLock()
> (lock-B) before requesting lock-A.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
