Unicast bundling breaks MERGE3 with TCP transport ------------------------------------------------- Key: JGRP-1588 URL: https://issues.jboss.org/browse/JGRP-1588 Project: JGroups Issue Type: Bug Affects Versions: 3.2.3, 3.2.4, 3.2.5, 3.2.6, 3.2.7, 3.3 Reporter: David Hotham Assignee: Bela Ban Fix For: 3.2.8, 3.3 Start with two sub-groups [A] and [B,C]. What's supposed to happen is that MERGE3 sends INFO messages around that get seen by everyone, and then since there's more than one view out there it can figure out that a merge is required. What actually happens is that INFO messages from A are seen only by A, and INFO messages from B and C are seen only by B and C. So no-one sees that a merge is required. I think that this is related to the code in TP.java that goes: {code} if(dest instanceof PhysicalAddress) { // We can modify the message because it won't get retransmitted. The only time we have a physical address // as dest is when TCPPING sends the initial discovery requests to initial_hosts: this is below UNICAST, // so no retransmission msg.setDest(null); } {code} Contrary to that comment, MERGE3's INFO messages use a physical address as dest. So we execute this code. Then I think that what happens is that by the time the bundler gets to sending these INFO messages, it thinks they're broadcast message. If you have a TCP transport that means that they are sent only to those members that are already in your group - which misses the point altogether.