[
https://issues.apache.org/jira/browse/GEODE-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender resolved GEODE-5162.
---------------------------------
Fix Version/s: 1.12.0
Resolution: Fixed
Resolving this fixed without an associated PR, because it's been addressed in
several other PRs over the course of related development. In general a ticket
like this needs to be written much more specifically, because it's not actually
possible to know that we've fixed _all_ possible permutations of the race
condition in question. It has, however, been addressed systematically, in the
form of the doIfDestroyNotPending method on, I believe, CacheImpl.
> Race condition between cache destruction and background thread cache access
> ---------------------------------------------------------------------------
>
> Key: GEODE-5162
> URL: https://issues.apache.org/jira/browse/GEODE-5162
> Project: Geode
> Issue Type: Bug
> Components: native client
> Reporter: Ryan McMahon
> Priority: Major
> Fix For: 1.12.0
>
>
> A race condition exists where the cache is accessed after it has been
> destroyed in one of the many background threads created for various reasons
> (failover, cleanup, periodic acks, etc).
> TcrConnectionManager.startFailoverAndCleanupThreads()
> ThinClientPoolHADM.startBackgroundThreads()
> HostSampler.start()
> There are probably other places where background threads are spun up as well,
> but these are the ones that were found in our tests.
> There is no synchronization between these background threads and the thread
> which destroys the cache, so it is possible that the background threads
> access the cache after destruction. We should investigate a robust way of
> synchronizing between the thread that creates/destroys the cache and the
> background threads, or evaluate if we can eliminate the dependency on the
> cache in the background threads.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
