Does this mean auto-reconnect is broken as well?
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
>
