[infinispan-dev] [infinispan-internal] async processing documentation (+ nice inconsistency scenario example)

Bela Ban bban at redhat.com
Wed Mar 20 04:26:00 EDT 2013



On 3/19/13 6:32 PM, Dan Berindei wrote:



> So yes, this can be done much better, but that means a fair few
> changes in JGroups such that:
>
> * Marshalling happens in the async thread (the same one that puts the
> message on the wire) rather than in the caller's thread *


JGroups doesn't use a different thread to pass the message down the 
stack until we hit the transport, where the message is added to a 
bounded queue, from which the message bundler threads removes and sends it.

> sendMessage() should accept a marshaller and unmarshaller per
> invocation

-1



> The upper-most protocol in the default stack is FRAG2, and it already
>  needs the serialized payload


Correct, although the message is not serialized at this point, I just 
use size() on all headers, which computes the serialized size of the 
headers.


> - it can't split an Object in 2
> messages. Most other protocols need at least the message size. So
> there's no way our payload is going to get serialized only in the TP
> thread that actually puts the bytes on the wire.


Correct


> In fact, I would go the other way around. Because we have multiple
> marshallers, I think it would be cleaner if we used MessageDispatcher
>  directly and did the request/response serialization in Infinispan.


+1


> I wouldn't recommend async marshalling anyway. The user must be very
>  careful not to modify the value object at any time after calling
> cache.put(key, value), so to me using async marshalling is just
> asking for trouble.


+1



-- 
Bela Ban, JGroups lead (http://www.jgroups.org)


More information about the infinispan-dev mailing list