Hi Olaf
Olaf Krische wrote:
> Hello again,
>
> ok, this is what i have in the moment:
>
> - a bunch of hosts connected to a hub. the hub propagates
> incoming messages to the other hostss except to the originating host.
>
> I wanna replace the hub by adding at least two rendezvous peers, which
> will inherit the task of propagating the messages to all other peers.
>
> What i want to avoid is that each host maintains connections to all
> other hosts on the net. They always should use the rendezvous peers
> to find hosts and to send messages to them. As well i can not use
> multicast.
>
> Now the questions:
>
> - IS_BOOTSTRAPPING_NODE
>
>
>> Represents a key whose value is set to true if this node will be a
>> bootstrapping host for other members to use for discovery purposes.
>> This is particularly useful when multicast traffic is not supported in the
>> network or cluster members are located outside a multicast supported
>> network area. Setting the value of this to true requires specifying a
>> URI corresponding to this member process's IP address and port with tcp
>> protocol, as a value in the VIRTUAL_MULTICAST_URI_LIST property. See
>> below for the VIRTUAL_MULTICAST_URI_LIST property
>>
>
> This tells me, when i setup a bootstrapping node, this node must also
> be given in the VIRTUAL_MULTICAST_URI_LIST ? Why?
>
Specifying that this is a bootstrapping node is not enough. GMS needs to
be told which address and port to use for binding. The list can contain
one or more rendezvous seed addresses. In the bootstrapping node,
specifying the virtual multicast uri list tells GMS to setup Jxta with
the specified rendezvous seed uri and the port value is used for both
binding the rendezvous service and for all Jxta communications as a tcp
port.
> - VIRTUAL_MULTICAST_URI_LIST
>
>
>> This enum represents a key the value of which is a comma separated list
>> of initial bootstrapping tcp addresses. This address list must be
>> specified on all members of the cluster through this property.
>>
>
>
>> Typically an address uri would be specified as tcp://ipaddress:port
>> The port here could be any available unoccupied port.
>>
>
> No, it must be the ipaddress:port of the bootstrapping node, right?
>
That's right. We should correct the Javadoc. What the doc is trying say
(albeit could say it better:) ) is that the port that the bootstrapping
node could pick is any unoccupied port in its system. The rest of the
nodes that want to use this rendezvous seed need to specify the
bootstrapping node's rendezvous seed uri.
>> Specifying this list is helpful particularly when cluster members are
>> located beyond one subnet or multicast traffic is disabled. Note: The
>> implementation in Shoal at the moment only uses the first address in
>> this list and ignores the rest. This is an enhancement that is not yet
>> completed.
>>
>
> Hrm. So this means, i would be stuck to one Hub again? What if this node
> gets lost?
>
With current code, I guess this is an issue (Mo should be able to say
more about this).
We have had severe time constraints to get to this although a few
community members have asked for this to be addressed.
I would heartily welcome any help in this area.
I wrote up this document a while ago but the cross subnet feature needs
testing, fixing and made workable:
http://wikis.sun.com/display/shoal/Shoal+How-To+-+Configuring+for+cross+subnet+support
> Maybe i just do not understand it right, is a rendezvous node really
> only necessary to find hosts? Once a host/peers has discovered its
> peers, it will send messages directly? Mh, no. This i do not want.
>
In my understanding of Jxta, the rendezvous node is used as a virtual
router for all messages in the group. All nodes communicate through the
rendezvous node. I understand from previous discussions that specifying
multiple rendezvous seeds distributes the load of routing among these
rendezvous seeds.
> Well, iam frustrated anyways. The more i dive into jxta, the more i get
> lost. Sometimes the dudes talk about RDV, and then they say Rendezvous
> again, then there is seed uri or seeds uri, and then i cant even
> simulate many hosts on one host withine a junit test.
>
I think this one is for Mo to answer. I have some but not an exhaustive
knowledge of Jxta as Mo does.
> Sigh :)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>
>