[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


> 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 

> - 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.


> 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.


> 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.


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

More information about the infinispan-dev mailing list