A server/peer can have its own cache configuration addition to cluster-configuration; if we still support that; does the new "reloadNewClusterConfiguration()" takes care of it?
-Anil. On Wed, Mar 21, 2018 at 1:06 PM, Jinmei Liao <jil...@pivotal.io> wrote: > 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 >
