[jboss-jira] [JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used

[Neal Dillman (JIRA)]

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

Neal Dillman edited comment on JGRP-2098 at 9/1/16 5:16 PM:
------------------------------------------------------------

In our implementation we created:
{{public class LESS_PING extends PING
{
    @Override
    public void findMembers( List<Address> members, boolean initial_discovery, Responses responses )
    {
        // no discovery except for the initial request
        if ( initial_discovery )
        {
            try
            {
                sendDiscoveryRequest( cluster_name, members );
            }
            catch ( InterruptedIOException ie )
            {
                ;
            }
            catch ( InterruptedException ex )
            {
                ;
            }
            catch ( Throwable ex )
            {
                log.error( Util.getMessage( "FailedSendingDiscoveryRequest" ), ex );
            }
        }
    }

    protected void sendDiscoveryResponse(Address logical_addr, PhysicalAddress physical_addr,
                                         String logical_name, final Address sender, boolean coord) {
        final PingData data=new PingData(logical_addr, is_server, logical_name, physical_addr).coord(coord);
        final Message rsp_msg=new Message(sender).setFlag(Message.Flag.INTERNAL, Message.Flag.OOB,
                                                          Message.Flag.DONT_BUNDLE)
          .putHeader(this.id, new PingHeader(PingHeader.GET_MBRS_RSP)).setBuffer(marshal(data));

        if(stagger_timeout > 0) {
            int view_size=view != null? view.size() : 10;
            int rank=Util.getRank(view, local_addr); // returns 0 if view or local_addr are null
            if( rank > 5 )
            {
                // there will be plenty of responders
                log.trace("%s: received GET_MBRS_REQ from %s, skipping response due to rank %d > max allowed of %d",
                          local_addr, sender, rank, max_rank_for_response );
            }
            else
            {
                long sleep_time = rank == 0 ? Util.random( stagger_timeout )
                    : stagger_timeout * rank / view_size - (stagger_timeout / view_size);
                timer.schedule( new Runnable()
                {
                    @Override
                    public void run()
                    {
                        log.trace( "%s: received GET_MBRS_REQ from %s, sending staggered response %s", local_addr, sender,
                                   data );
                        down_prot.down( new Event( Event.MSG, rsp_msg ) );
                    }
                }, sleep_time, TimeUnit.MILLISECONDS );
            }
        }
        else
        {
            log.trace( "%s: received GET_MBRS_REQ from %s, sending response %s", local_addr, sender, data );
            down_prot.down( new Event( Event.MSG, rsp_msg ) );
        }
    }
}
}}
This in effect limits discovery to initial discovery.  In addition, discovery only responds if the rank < 5.  Both of these changes work together to most eliminate discovery from the channel (because we have the IP address in the UUID)


was (Author: ndillman):
In our implementation we created:
public class LESS_PING extends PING
{
    @Override
    public void findMembers( List<Address> members, boolean initial_discovery, Responses responses )
    {
        // no discovery except for the initial request
        if ( initial_discovery )
        {
            try
            {
                sendDiscoveryRequest( cluster_name, members );
            }
            catch ( InterruptedIOException ie )
            {
                ;
            }
            catch ( InterruptedException ex )
            {
                ;
            }
            catch ( Throwable ex )
            {
                log.error( Util.getMessage( "FailedSendingDiscoveryRequest" ), ex );
            }
        }
    }

    protected void sendDiscoveryResponse(Address logical_addr, PhysicalAddress physical_addr,
                                         String logical_name, final Address sender, boolean coord) {
        final PingData data=new PingData(logical_addr, is_server, logical_name, physical_addr).coord(coord);
        final Message rsp_msg=new Message(sender).setFlag(Message.Flag.INTERNAL, Message.Flag.OOB,
                                                          Message.Flag.DONT_BUNDLE)
          .putHeader(this.id, new PingHeader(PingHeader.GET_MBRS_RSP)).setBuffer(marshal(data));

        if(stagger_timeout > 0) {
            int view_size=view != null? view.size() : 10;
            int rank=Util.getRank(view, local_addr); // returns 0 if view or local_addr are null
            if( rank > 5 )
            {
                // there will be plenty of responders
                log.trace("%s: received GET_MBRS_REQ from %s, skipping response due to rank %d > max allowed of %d",
                          local_addr, sender, rank, max_rank_for_response );
            }
            else
            {
                long sleep_time = rank == 0 ? Util.random( stagger_timeout )
                    : stagger_timeout * rank / view_size - (stagger_timeout / view_size);
                timer.schedule( new Runnable()
                {
                    @Override
                    public void run()
                    {
                        log.trace( "%s: received GET_MBRS_REQ from %s, sending staggered response %s", local_addr, sender,
                                   data );
                        down_prot.down( new Event( Event.MSG, rsp_msg ) );
                    }
                }, sleep_time, TimeUnit.MILLISECONDS );
            }
        }
        else
        {
            log.trace( "%s: received GET_MBRS_REQ from %s, sending response %s", local_addr, sender, data );
            down_prot.down( new Event( Event.MSG, rsp_msg ) );
        }
    }
}

This in effect limits discovery to initial discovery.  In addition, discovery only responds if the rank < 5.  Both of these changes work together to most eliminate discovery from the channel (because we have the IP address in the UUID)

> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
>                 Key: JGRP-2098
>                 URL: https://issues.jboss.org/browse/JGRP-2098
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)