Re: Recreate Cache -- is it possible?

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 wrote: > Sounds like this is a slippery

Re: Recreate Cache -- is it possible?

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

Re: Recreate Cache -- is it possible?

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

Re: Recreate Cache -- is it possible?

Does this mean auto-reconnect is broken as well? On Wed, Mar 21, 2018 at 10:28 AM Jinmei Liao 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

Re: Recreate Cache -- is it possible?

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 wrote: > It's likely that the JVM is exiting because the AcceptorImpl thread is the > only non-daemon thread and it is

Re: Recreate Cache -- is it possible?

Kirk: good call. I will see if I can add an interface method to the InternalCache. On Wed, Mar 21, 2018 at 10:13 AM, Kirk Lund wrote: > I'm actively working to remove direct usage of GemFireCacheImpl from all of > our code. Is there a reason you have to directly use

Re: Recreate Cache -- is it possible?

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

Re: Recreate Cache -- is it possible?

I'm actively working to remove direct usage of GemFireCacheImpl from all of our code. Is there a reason you have to directly use GemFireCacheImpl? This is going to add one more thing that I have to change. Maybe the VM exit is happening because you've forked a new VM with ServerLauncher or

Re: Recreate Cache -- is it possible?

Great, how do we trigger cache.close indicating auto-reconnect? On Wed, Mar 21, 2018 at 10:08 AM, Anilkumar Gingade wrote: > Instead of adding new feature; can we address the issue with VM exit. The > auto-reconnect feature does cache close without exiting the VM. > >

Re: Recreate Cache -- is it possible?

Instead of adding new feature; can we address the issue with VM exit. The auto-reconnect feature does cache close without exiting the VM. -Anil. On Wed, Mar 21, 2018 at 9:48 AM, Jinmei Liao wrote: > We would like to allow users to import a new set of cluster configuration

Recreate Cache -- is it possible?

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