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
>
