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 <kl...@pivotal.io> 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 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
> > >
> >
>
--
Cheers
Jinmei
