geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jinmei Liao <jil...@pivotal.io>
Subject Re: Recreate Cache -- is it possible?
Date Wed, 21 Mar 2018 20:06:23 GMT
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

Basically this is what the reloadClusterConfiguration does:
https://github.com/apache/geode/pull/1656/files#diff-14ace6c5abf2f68c480b55a7c882e18c

If you see anything obviously wrong, or even vaguely wrong, please comment
on the PR, we will try to test it out.

Thanks!

On Wed, Mar 21, 2018 at 12:42 PM, Kirk Lund <klund@apache.org> wrote:

> 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 <jiliao@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 <
> bschuchardt@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
> >
>



-- 
Cheers

Jinmei

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message