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

[Manik Surtani]

On 27 Nov 2006, at 22:01, Bela Ban wrote:

>
>
> 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.
>

Another option (equally hacky, but again temporary until JG 2.5) is  
for TreeCache (or RpcManager in 2.0.0) to test whether UDP is a  
registered protocol in the channel (Iterate through the Vector  
returned by channel.getProtocolStack().getProtocols() and look for an  
instance of o.j.p.UDP).  If UDP is registered, then ALWAYS use  
callRemoteMethods() otherwise ALWAYS use separate callRemoteMethod()  
invocations.

Which would be cleaner/more efficient?  I'd go for option 2, provided  
there is no efficiency lost when broadcasting to the entire cluster  
using a series of callRemoteMethod() invocations over a single  
callRemoteMethods() invocation when using TCP.