[infinispan-dev] ISPN-1384 - InboundInvocationHandlerImpl should wait for cache to be started? (not just defined)

[Dan Berindei]

On Tue, Sep 27, 2011 at 5:59 PM, Galder Zamarreño <galder at 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.

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.

Cheers
Dan


> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>