On Mon, Sep 14, 2015 at 2:46 PM, Pedro Ruivo <pedro(a)infinispan.org> wrote:
Hi,
I found the following issues with _EmbeddedCacheManager.removeCache()_
while I was helping the LEADS devs. The method removes the cache from
all the nodes in the cluster.
#1 It has different behaviour in the invoker node.
In the invoked node, it removes the configuration from
_configurationOverrides_ field and from _cacheDependencyGraph_. In the
remaining node, it doesn't.
To think: it should remove from _cacheDependencyGraph_ in all the nodes
but keep the configuration.
Galder added the _configurationOverrides_ removal for ISPN-3234, so
I'm guessing JCache needs it.
I guess the problem is that as long as the configuration exists,
manager.getCache(name) will re-create the cache, and that doesn't fit
with JCache. I'd rather remove the cache from _configurationOverrides_
everywhere, at least until we stop auto-spawning caches.
#2 It tries to remove the cache remotely before locally.
It could be done in parallel and it has a small issue: if a timeout
occurs, it never tries to remove the cache locally.
To think: can we send the request asynchronously?
+1 to do it asynchronously
#3 When passivation is enabled, it first invoke
_PassivationManager.passivateAll()_ and then _PersistenceManager.stop()_.
The former will copy all the data in memory to the cache store and the
later will clear the cache store. We can skip the passivation.
To think: create a _PassivationManager.skipPassivationOnStop()_ (similar
to _PersistenceManager.setClearOnStop()_).
Personally I was never really happy with removeCache() always purging
the store. Although it makes sense for temporary caches, it means
we're missing a way to just stop a cache on all the nodes.
Maybe add a (mutable?) configuration option
AbstractStoreConfiguration.purgeOnStop that could be referenced by
both the PassivationManager and the PersistenceManager instead?
Cheers
Dan