Re: [infinispan-dev] ISPN-293 getAsync impl requires more reengineering

The problem that I see with that is getAsync() calls that should resolve locally will get the penalty of the thread context switching. I think I have a workable solution without having to rely on your suggestion which passes the test suite. I'll send a pull request and you (Mircea+Manik) can have a look to it, and then we can decide :) On Feb 9, 2011, at 2:32 PM, Mircea Markus wrote: > > On 9 Feb 2011, at 12:34, Manik Surtani wrote: > >> What about putting the entire call on a separate thread much earlier in the call stack? E.g., in the CacheDelegate? You get the added benefit of any cache loading happening offline as well. Plus a much simpler impl. :) > +1. >> >> Sent from my iPhone >> >> On 9 Feb 2011, at 08:14, Galder Zamarreño <galder(a)redhat.com&gt; wrote: >> >>> Hi, >>> >>> Re: https://issues.jboss.org/browse/ISPN-293 >>> >>> I have an issue with my implementation that simply wraps the realRemoteGet in DistributionInterceptor around a Callable: >>> >>> Assume that cache is configured with Distribution(numOwners=1, l1=enabled), no transactions, and we have a cluster of 2 nodes: >>> >>> - [main-thread] Put k0 in a cache that should own it. >>> - [main-thread] Do a getAsync for k0 from a node that does not own it: >>> - [async-thread] This leads to a remote get which updates the L1 and updates the context created by the main-thread and putting the updated entry in there (however, this thread does not release the locks) >>> - [main-thread] Next up, we put a new key, i.e. k1, in the node that didn't own k0 (the node where we updated the L1 cache): >>> - Now this thread has used the same context that the async thread used, so when it comes to releasing locks, it finds two entries in the context, the one locked by the async-thread and one for the main-thread and it fails with java.lang.IllegalMonitorStateException >>> >>> Now, what's happening here is the async-thread is acquiring the lock but not releasing it because the release happens in the DistLockInterceptor/LockingInterceptor, so a different interceptor to where the lock is being acquired. So, in theory, the solution would be for DistLockInterceptor to wrap the invokeNext() and afterCall() for when an async get so that all "remote get", "l1 update", and "release locks", happen in a separate thread. However, for this to work, it will need to figure out whether a remoteGet() will be necessary in the first place, otherwise is useless. Whether the remoteGet should happen is determined by this code in DistributionInterceptor: >>> >>> if (ctx.isOriginLocal() && !(isMappedToLocalNode = dm.isLocal(key)) && isNotInL1(key)) { >>> >>> Also, if DistLockInterceptor does this check, we need to make sure DistributionInterceptor does not do it again, otherwise it's a waste. I think this might work although it does require some further reengineering. >>> >>> I'm gonna try to implement this but wondering whether anyone can see any potential flaws here, or if anyone has any better ideas :) >>> >>> Cheers, >>> -- >>> Galder Zamarreño >>> Sr. Software Engineer >>> Infinispan, JBoss Cache >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev