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

[Bela Ban]

Yes, you could call getChannel().getProtocolStack().findProtocol("UDP") 
to do this.

I discussed this yesterday, and the impl of anycast is really quite 
simple. I'll do this next week.

Manik Surtani wrote:
>
>
> 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.
>
>

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