I tried this out, and it does not work. If one R&R node has no knowledge of the
other's listening address, they are not able to join together into a group. This
seems like rather a limitation to me: there could be an existing group spread
across several subnets, but now that a new subnet needs to come into the system,
all the other R&R nodes need to be restarted.
-Jerry
Jerry Raj wrote:
> Ok, thansk, that sounds good. In short, in each subnet, we need at least one R&R
> node, and more than one to improve availability.
> The answer to my other question is less clear: is it ok for R&R nodes to not
> have knowledge of *all* other R&R nodes? For eg:
> 1. on subnet1, we bring up 5 peers and 1 R&R, which has
> VIRTUAL_MULTICAST_URI_LIST populated with only itself
> 2. on subnet2, an R&R node is brought up with its URI list showing both itself
> and the one on subnet1
> 3. 5 non-R&R peers come up on subnet2
>
> Will the above work reliably? My testing shows that it works, but can I rely on
> it working, since the docs explictly state that all R&R nodes must have the same
> URI list?
>
> Another thing that I just thought of, what happens if we reverse the order of 2
> & 3 in my scenario? I'm guessing that two independent groups will be created,
> and then merge into one. Will join events be fired when they merge?
>
> -Jerry
>
> Mohamed Abdelaziz wrote:
>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
>> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>>
>