On Sep 28, 2011, at 4:06 PM, Galder Zamarreño wrote: > > On Sep 27, 2011, at 6:50 PM, Dan Berindei wrote: > >> On Tue, Sep 27, 2011 at 5:59 PM, Galder Zamarreño <gal...@redhat.com> wrote: >>> Hi, >>> >>> Re: https://issues.jboss.org/browse/ISPN-1384 >>> >>> I've had a look to this and this race condition could, in theory, be >>> resolved by making InboundInvocationHandlerImpl.handle() waiting for cache >>> not only to be defined, but to be started. Otherwise there'll always be a >>> potential race condition like the one showed in the log. >>> >> >> Actually I think it would be enough to wait until the cache has >> started joining (StateTransferManager.waitForJoinToStart()), that >> means all the other components have finished starting. > > Sounds good to me.
Couple of things: 1. In this particular case, waiting for that would work because this clustered get is a cluster wide one, so there's no need for this node to wait for state transfer to occur. InboundInvocationHandlerImpl.handle could be hacked to check on the cache's StateTransferManager.waitForJoinToStart() but seems a bit hacky. 2. In BaseStateTransferManagerImpl.start it says: " // needs to be AFTER the DistributionManager and *after* the cache loader manager (if any) inits and preloads" CacheLoaderManagerImpl.preload has priority 56, compared to BaseStateTransferManagerImpl.start which has 21, so state transfer could start before preloading has occurred? > >> >> With the asymmetric cache support in place I think we shouldn't have >> to wait at all, since we'll send the join request only after all the >> components have been started. We could either apply the commands (if >> we implement the non-blocking state transfer option) or reject them >> and tell the originator to retry after the state transfer is done (if >> we keep the blocking state transfer, since the other nodes shouldn't >> be sending commands to us anyway). >> >>> In this particular case, this is clustered get command being received from >>> a clustered cache loader, which is arriving in the cache before this is >>> started (and the cache loader has been created, hence the NPE). >>> >>> Another question, is there any reason why CacheLoader is not a named cache >>> component which can be initalised with a corresponding factory and to which >>> other components can be injected (i.e. marshaller, cache...etc)? >>> >>> In this particular case, this would also resolve the issue because >>> ClusterCacheLoader.start() does nothing, so all the interceptor needs is a >>> proper instance of ClusterCacheLoader available. The factory makes these >>> available bejore inject. >>> >>> Thoughts? >>> >>> Cheers, >>> >>> p.s. Dan, I am aware of https://issues.jboss.org/browse/ISPN-1324, maybe >>> you're solving this indirectly with the work for that JIRA? >> >> With asymmetric caches in place I don't think we'll need/want >> ISPN-1324 any more. > > +1 > >> >> Cheers >> Dan >> >> >>> -- >>> Galder Zamarreño >>> Sr. Software Engineer >>> Infinispan, JBoss Cache >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
