[jbosscache-dev] Anycast: JBCACHE-813 & JGRP-338

Bela Ban bela at jboss.org
Mon Nov 27 17:01:59 EST 2006



Manik Surtani wrote:
> Bela/Vladimir:
>
> Regarding broadcasting calls to a subset of members in a cluster, if I 
> were to callRemoteMethods() to N members ( where N > 1 and N < all 
> members) how does this behave, especially when using TCP or TCP_NIO?  
> I know that with UDP, a multicast is made and the members not on the 
> target list ignore the messages.  Is this the same with TCP/TCP_NIO

yes

> i.e., is the message broadcast to all members again and the members 
> not on the target list ignore the messages?  (Hugely wasteful, and 
> hence the need for anycast).

Right (http://jira.jboss.com/jira/browse/JGRP-338)

> In JBoss Cache 1.4.1, I've implemented JBCACHE-813 so a unicast is 
> used if the recipient list is 1 - a bit of a hack to work around this 
> inefficiency.  But this in itself is not foolproof since, say using 
> Buddy Replication in a cluster of 30 servers and using 3 buddies per 
> node, we still end up unicasting the message to all 30 nodes only for 
> 27 of them to ignore it.

Correct. I think anycast will be relatively simple to implement. In the 
meantime, you could simply send 3 unicasts yourself, e.g. for sending 
the message to A, B and C:
callRemoteMethod(A, "foo", new Object[]{"bla", new Integer(2662)}, new 
Class[]{String.class, Integer.class}, ...);
callRemoteMethod(B, "foo", new Object[]{"bla", new Integer(2662)}, new 
Class[]{String.class, Integer.class}, ...);
callRemoteMethod(C, "foo", new Object[]{"bla", new Integer(2662)}, new 
Class[]{String.class, Integer.class}, ...);

This should do the job.

> We could hack in a config param - a unicast threshold (UT) - where if 
> N <= UT and N <= all members, we use a series of forced unicasts?  The 
> drawback is that this only makes sense with TCP/TCP_NIO.  Using this 
> with UDP will probably result in worse performance since a single 
> broadcast would be better. 

Yes, the idea is to let the transport handle optimal message 
distribution, e.g. as described in the above JIRA issue. This will be 
available in 2.5.

-- 
Bela Ban
Lead JGroups / JBoss Clustering team
JBoss - a division of Red Hat



More information about the jbosscache-dev mailing list