[
https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin....
]
Bela Ban updated JGRP-2098:
---------------------------
Comment: was deleted
(was: 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
Attachments: LESS_PING.java
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)