[infinispan-dev] [infinispan-internal] async processing documentation (+ nice inconsistency scenario example)
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
> 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