[infinispan-dev] inefficient usage of CacheLoader with REPL

[Manik Surtani]

Interesting thread.  I think this is what we should do, given that the ResponseGenerator already bypasses serialising unnecessary return values.

Further, I think loading from a cache store is entirely unnecessary for the remote node, for both REPL and DIST, except:

* Until we have https://issues.jboss.org/browse/ISPN-317 implemented.  In which case (only) the primary owner/coordinator will still need to load from store.
* We are using write skew checks, and have eviction enabled.  Again in which case only the primary owner/coordinator will still need to load from store, to be able to perform a version comparison.

In all other cases loading from the cache store should not happen on the remote node!  :)

I'll take a look at the size/complexity/risk of such a patch, but any more thoughts from you guys will be much appreciated.

Cheers
Manik

On 21 Dec 2011, at 10:35, Dan Berindei wrote:

>> Dan, thanks for looking. So it ignores the return values: wouldn't it
>> be more efficient to ask the remote node to not serialize it at all in
>> first place?
>> I mean ReplicationInterceptor should send over both
>> Flag.SKIP_CACHE_LOAD (*not* X_LOAD) and Flag.SKIP_REMOTE_LOOKUP
>> on any write operation.
>> 
> 
> Flag.SKIP_REMOTE_LOOKUP shouldn't be necessary, the ResponseGenerator
> on the remote node checks the command ID before serializing the
> response and sends a null instead if the command is not one of those
> listed in DefaultResponseGenerator.requiresResponse (for replicated
> and invalidation caches).
> 
> The ResponseGenerator does seem a bit "magic", so perhaps it would be
> better to use Flag.SKIP_REMOTE_LOOKUP instead and maybe add a generic
> Flag.IGNORE_REMOTE_RESPONSE if there are other commands that would
> benefit from it. Definitely something for 5.2 :)
> 
> Cheers
> Dan
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20111221/b4ec0029/attachment-0001.html