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 LocatorLauncher? I think those launchers create a loop in
the main thread which keeps the process alive -- if something causes that
main thread to terminate then the VM will go away.
On Wed, Mar 21, 2018 at 10:08 AM, Anilkumar Gingade <aging...@pivotal.io>
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.
>
> -Anil.
>
>
>
>
> On Wed, Mar 21, 2018 at 9:48 AM, Jinmei Liao <jil...@pivotal.io> 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
> >
>
