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
