This works if the following is met :
- all R&R nodes are aware of a common seed
- if a joining R&R discovers (through multicast) the seed/other R&R
nodes through multicast from neighboring nodes
On 7/14/09 2:16 AM, Jerry Raj wrote:
> 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
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>
>