You must at least designate a single node (or more for availability) as
the seed node in such an environment, in order to overcome churn in the
cluster. In addition, and depending on the cluster size, you may
designate additional nodes to take on that role (10-1 ratio), as they
are discovered, they will be used in the event the seed nodes seize to
operate, or for load distribution.
Mohamed
On 7/10/09 3:13 AM, Jerry Raj wrote:
> Hi Folks,
> I've been able to get shoal working across subnets as described in [1]. In that
> document, it states that VIRTUAL_MULTICAST_URI_LIST should be the same across
> all peers. This may not be feasible, since the lifetime of the group may be
> quite long and peers may come and go across different subnets. Each time a peer
> shows up in a new subnet, it may be possible to discover (out-of-band) the
> existing R&R nodes, but the existing R&R nodes will not add this new peer to
> their VIRTUAL_MULTICAST_URI_LISTs.
> In my testing, I could actually see that the above scenario actually worked
> fine, ie even when some R&R nodes do not know about all the other R&R nodes. Can
> I rely on this behavior?
> In a related question, I could even see group membership and messaging working
> fine across subnets when VIRTUAL_MULTICAST_URI_LIST was not set for non-R&R
> nodes. Is this a defined behavior?
>
> -Jerry
> [1]
> http://wikis.sun.com/display/shoal/Shoal+How-To+-+Configuring+for+cross+subnet+support
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>
>