[jira] [Resolved] (GEODE-5162) Race condition between cache destruction and background thread cache access

["Blake Bender (Jira)" <ji...@apache.org>]

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