[jboss-jira] [JBoss JIRA] (JGRP-1588) Unicast bundling breaks MERGE3 with TCP transport

[David Hotham (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753359#comment-12753359 ] 

David Hotham commented on JGRP-1588:
------------------------------------

Great, thanks. 

I should add that this isn't tremendously important to me.  I spotted it because you've changed the default for unicast bundling (was False, now True) - which broke things for me.  But having understood that this is the issue, I can easily work around the problem by turning unicast bundling off again.

Therefore, no great urgency on this from my point of view.
                
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira