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