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.