[infinispan-dev] DIST.retrieveFromRemoteSource

[Bela Ban]

On 2/5/12 5:06 PM, Dan Berindei wrote:
> 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".


Correct.


> I will modify our CommandAwareRpcDispatcher to use GroupRequest and
> see how they compare, then we can continue this discussion with the results.

Excellent, I'm curious to see whether this makes any difference !
Cheers,

-- 
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat