Sounds like this is a slippery slope. I reworked the strategy: instead of calling cache.close, I only issue a call to the locator to get the cluster configuration again and do a reload of the properties and cacheXml. Here is the PR for this approach: https://github.com/apache/geode/pull/1656
Basically this is what the reloadClusterConfiguration does: https://github.com/apache/geode/pull/1656/files#diff-14ace6c5abf2f68c480b55a7c882e18c If you see anything obviously wrong, or even vaguely wrong, please comment on the PR, we will try to test it out. Thanks! On Wed, Mar 21, 2018 at 12:42 PM, Kirk Lund <kl...@apache.org> wrote: > The non-daemon thread in a process launched with ServerLauncher is looping > in waitOnServer. When you close the Cache, that loop exits and the > ServerLauncher process exits. > > As Bruce pointed you, JUnit and the DUnit VMs have other non-daemon > threads. > > You might need to alter ServerLauncher.waitOnServer() and > LocatorLauncher.waitOnLocator() for what you're doing. > > On Wed, Mar 21, 2018 at 10:28 AM, Jinmei Liao <jil...@pivotal.io> wrote: > > > Bruce: this sounds like the root cause of the differences between the > dunit > > test and reall app test. > > > > On Wed, Mar 21, 2018 at 10:22 AM, Bruce Schuchardt < > bschucha...@pivotal.io > > > > > wrote: > > > > > It's likely that the JVM is exiting because the AcceptorImpl thread is > > the > > > only non-daemon thread and it is stopped when the cache is closed. > DUnit > > > JVMs have a non-daemon main() thread that keeps them alive. > > > > > > > > > > > > On 3/21/18 9:48 AM, Jinmei Liao wrote: > > > > > >> We would like to allow users to import a new set of cluster > > configuration > > >> with running servers as long as we make sure these servers are vanilla > > >> servers (servers that are just started with nothing in it). Now since > > the > > >> servers are already up, caches are already created, we will need to > > >> re-create the cache with the new xml received from the locator. > > Originally > > >> our implementation on the servers boils down to: > > >> > > >> cache.close("Re-create Cache", true, true); > > >> > > >> GemFireCacheImpl.create(oldDs, cacheConfig); > > >> > > >> > > >> but the cache.close call eventually leads to a VM exit (somehow in the > > >> DUunit VM, it doesn not), so this does not work with real application > > >> environment. Now we are wondering is there a safe to recreate the > cache > > >> instance with a new set of properties/cacheXml without triggering the > > >> entire shutdown sequence? > > >> > > >> > > >> > > > > > > > > > -- > > Cheers > > > > Jinmei > > > -- Cheers Jinmei
