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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org