[infinispan-dev] DIST.retrieveFromRemoteSource
Dan Berindei
dan.berindei at gmail.com
Sun Feb 5 11:06:31 EST 2012
On Sun, Feb 5, 2012 at 5:56 PM, Bela Ban <bban at redhat.com> wrote:
>
>
> On 2/5/12 4:40 PM, Dan Berindei wrote:
>
>
>>> Remember that a message might be retransmitted, so it is placed into a
>>> retransmit buffer. If M1 has destination A and M2 has destination B, and
>>> we send M1 first (to A), then change M1's destination to B, and send it,
>>> everything is fine. However, if we later get a retransmit request from
>>> B, we'd resend the message to A instead ! This is just 1 example,
>>> modifications of headers is another one.
>>>
>>> Note that the copy does *not* copy the buffer (payload) itself, but only
>>> references it, so this is fast. Of course, nobody is supposed to modify
>>> the contents of the buffer itself...
>>>
>>
>> I wasn't clear enough, but I didn't mean we should reuse the entire
>> Message object. I meant we should copy the Message but not the buffer
>> or the headers. I see now that protocols may be adding new headers, so
>> it wouldn't be safe to reuse the headers collection.
>>
>> I think this line in
>> RequestCorrelator.sendRequest(RequestCorrelator.java:152) means that
>> the contents of the buffer is copied in the new message, not just the
>> buffer reference:
>>
>> Message copy=msg.copy(true);
>
>
> No, this does *not* copy the buffer, but simply references the same buffer.
>
Aha, I thought copy_buffer == true meant "copy the contents" and
copy_buffer == false meant "share the contents". I see copy_buffer ==
true actually means "copy the reference, share the contents" and
copy_buffer == false means "don't copy anything".
I will modify our CommandAwareRpcDispatcher to use GroupRequest and
see how they compare, then we can continue this discussion with the
results.
Cheers
Dan
More information about the infinispan-dev
mailing list