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

[Brian Stansberry]

Re: making multiple unicast calls from the JBC layer, doesn't this
likely increase the overall time to do the group RPC by putting each
call/response in series? You lose JGroups' ability to correlate the
responses.

jbosscache-dev-bounces at lists.jboss.org wrote:
> 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.