On 2/5/12 5:06 PM, Dan Berindei wrote: > On Sun, Feb 5, 2012 at 5:56 PM, Bela Ban<b...@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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev