[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:all-tabpanel ]

David Hotham updated JGRP-1588:
-------------------------------

    Description: 
Eg 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 figures 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 PhysicalAddresses.  So I think that what happens is that by the time the bundler gets to sending them, it thinks they're broadcast messages; and then 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.

  was:
Eg 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 figures 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:

        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);
        }



    
> 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
>
> Eg 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 figures 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 PhysicalAddresses.  So I think that what happens is that by the time the bundler gets to sending them, it thinks they're broadcast messages; and then 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