[infinispan-dev] Caches need be stopped in a specific order to respect cross-cache dependencies

[Dan Berindei]

On Mon, Aug 25, 2014 at 10:26 AM, Galder Zamarreño <galder at redhat.com>
wrote:

>
> On 15 Aug 2014, at 15:55, Dan Berindei <dan.berindei at gmail.com> wrote:
>
> > It looks to me like you actually want a partial order between caches on
> shutdown, so why not declare an explicit dependency (e.g.
> manager.stopOrder(before, after)? We could even throw an exception if the
> user tries to stop a cache manually in the wrong order (e.g.
> TestingUtil.killCacheManagers).
> >
> > Alternatively, we could add an event CacheManagerStopEvent(pre=true) at
> the cache manager level that is invoked before any cache is stopped, and
> you could close all the indexes in that listener. The event could even be
> at the cache level, if it would make things easier.
>
> Not sure you need the listener event since we already have lifecycle event
> callbacks for external modules.
>
> IOW, couldn’t you do this cache stop ordering with an implementation of
> org.infinispan.lifecycle.ModuleLifecycle? On cacheStarting, you could maybe
> track each started cache and give it a priority, and then on
> cacheManagerStopping use that priority to close caches. Note: I’ve not
> tested this and I don’t know if the callbacks happen at the right time to
> allow this. Just thinking out loud.
>
>
Unfortunately ModuleLifecycle.cacheManagerStopping is only called _after_
all the caches have been stopped.



> Cheers,
>
> >
> > Cheers
> > Dan
> >
> >
> >
> > On Fri, Aug 15, 2014 at 3:29 PM, Sanne Grinovero <sanne at infinispan.org>
> wrote:
> > The goal being to resolve ISPN-4561, I was thinking to expose a very
> > simple reference counter in the AdvancedCache API.
> >
> > As you know the Query module - which triggers on indexed caches - can
> > use the Infinispan Lucene Directory to store its indexes in a
> > (different) Cache.
> > When the CacheManager is stopped, if the index storage caches are
> > stopped first, then the indexed cache is stopped, this might need to
> > flush/close some pending state on the index and this results in an
> > illegal operation as the storate is shut down already.
> >
> > We could either implement a complex dependency graph, or add a method
> like:
> >
> >
> >   boolean incRef();
> >
> > on AdvancedCache.
> >
> > when the Cache#close() method is invoked, this will do an internal
> > decrement, and only when hitting zero it will really close the cache.
> >
> > A CacheManager shutdown will loop through all caches, and invoke
> > close() on all of them; the close() method should return something so
> > that the CacheManager shutdown loop understand if it really did close
> > all caches or if not, in which case it will loop again through all
> > caches, and loops until all cache instances are really closed.
> > The return type of "close()" doesn't necessarily need to be exposed on
> > public API, it could be an internal only variant.
> >
> > Could we do this?
> >
> > --Sanne
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Galder Zamarreño
> galder at redhat.com
> twitter.com/galderz
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140825/c7b3a4d3/attachment.html