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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

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

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