Jim Marino wrote:
> Hi Shreedhar,
>
> I've taken a further look at this and I have a few more questions. I
> think it may be easiest to start with what my mental model is for how
> rendezvous configuration would work as I may have incorrect
> assumptions. Here is how I understand the relationship between
> clusters and JXTA peer groups:
>
> 1. JXTA imposes the constraint that there can only be one World Peer
> Group per classloader, which essentially means one WPG per runtime
> instance. (I'm curious as to why JXTA seems to use statics in this
> respect but that is probably for another discussion)
> 2. A runtime instance can participate in multiple clusters, which are
> mapped in a 1..1 relationship with a Net Peer Group.
correct.
>
> If the above assumptions are correct, at first glance I would think
> rendezvous configuration should work like this:
>
> 1. A runtime instance may be configured as a rendezvous peer for 0..n
> clusters.
yes, provided it is a member in 1..n clusters.
> 2. Configuration would be on a per-cluster basis and include the
> following information:
> a. JxtaConfigConstants.IS_BOOTSTRAPPING_NODE - sets if the runtime
> acts as a rendezvous peer in the cluster
Correct. This is the seeding/or entry point to discovery dynamically
configured rendezvous nodes for the cluster. Let's say after the
cluster forms, a policy could be adopted, whereby n number of nodes
would dynamically take on the role of rendezvous for load distribution
(virtual multicast), and failover, where n is determined by the cluster
size, and self election based on the sort order in the cluster view or
geographical location.
> b. JxtaConfigConstants .VIRTUAL_MULTICAST_URI_LIST - sets the the
> list rendezvous seed URIs.
This is to support a pre-configured list of rendezvous points based on
policy of the admin. e.g. a static distribution map.
> c. A parameter to determine if multicast is enabled. If disabled,
> the rendezvous seed list must contain at least one value
multicast is recommended when running in a topology which supports it.
> d. A parameter to set the rendezvous TCP port for the cluster.
> This I believe is different from the current code in several respects.
> First, it means a TCP port must be explicitly set per cluster if the
> node is a rendezvous peer as opposed to imputing the port for the
> first entry in the list of seed URIs. Also, it involves not setting
> the TCP port at the WPG level. I have no idea if this is correct
> behavior with respect to JXTA. I'm assuming there are different
> rendezvous service instances per net peer group/cluster but perhaps
> there is one rendezvous service instance that participates in multiple
> peer groups? If it is the latter, then I guess the TCP port setting
> should be configured on the WPG.
By default, nodes are configured to dynamically select a port, A seed
rendezvous endpoint must be defined to enable virtual multicasting
>
> Item 2d would probably result in cleaning up some of the duplicate
> initialization code that appears in the WPG and domain initialization
> methods of NetworkManager. It seems that once this is done,
> non-multicast discovery should work, assuming there are no underlying
> issues I'm not aware of. I have the feeling there may be, given some
> of the CVS history I came across for NetworkManager...
Not sure I understand the above to be a bug, but I would be interested
to see the interpretation in code changes.
Cheers,
Mohamed
>
> Am I on the right track?
>
> Jim
>
>
>
>
> On Mar 2, 2009, at 6:28 PM, Shreedhar Ganapathy wrote:
>
>> Hi Jim
>> Thanks for starting to look around the code wrt cross subnet support.
>> cil below :
>>
>> Jim Marino wrote:
>>> Hi,
>>>
>>> I've been looking at enabling non-multicast discovery using
>>> rendezvous peers and a few questions have come up. First, I'm
>>> unclear on how a rendezvous peer should be configured. Specifically,
>>> how to specify the tcp port a rendezvous peer should listen on. I
>>> came across the following parameters:
>>>
>>> JxtaConfigConstants.IS_BOOTSTRAPPING_NODE
>>>
>>> I assume if set to true, this will enable the node as a rendezvous
>>> and relay node. And, the second parameter:
>>>
>>> JxtaConfigConstants .VIRTUAL_MULTICAST_URI_LIST
>>
>> Look in the script crosssubnetdemo[.sh/.bat] and specifically in the
>> test class named ApplicationServer.java on how these constants are
>> specified and passed in.
>>
>>>
>>> This collection appears to be used to specify the URIs of rendezvous
>>> nodes. But I also noticed the following in
>>> NetworkManager.startDomain():
>>>
>>> if (isRendezvousSeed && rendezvousSeedURIs.size() > 0) {
>>> config = new
>>> NetworkConfigurator(NetworkConfigurator.RDV_NODE +
>>> NetworkConfigurator.RELAY_NODE, storeHome.toURI());
>>> //TODO: Need to figure out this process's seed addr from
>>> the list so that the right port can be bound to
>>> //For now, we only pick the first seed URI's port and let
>>> the other members be non-seeds even if defined in the list.
>>> String myPort = rendezvousSeedURIs.get(0);
>>> .....
>>>
>>> My impression is this will be problematic when configuring multiple
>>> rendezvous peers.
>> Yes. That's right. It has been a hack for a long time as part of the
>> prototype work we did to see if this approach works with even one
>> rendezvous. It was working upto a certain point after which when we
>> introduced support for a member participating in multiple cluster,
>> the support for this broke somehow in the underlying code.
>>
>>> Shouldn't there be an explicit configuration for the TCP port to use?
>> That is specified as part of the passed in URI. tcp://ipaddress:port.
>> Its documented in the Javadoc. Or am I missing your question?
>> Also, the port to bind to as passed in is specified in line number
>>
>>> Related to this, I also noticed the NetworkConfigurator in
>>> NetworkManager.startDomain() is always enabled with multicast.
>>> Should this be optional? If there was a way to configure the TCP
>>> port and to specify whether multicast should be used, would that
>>> enable the use of a single rendezvous instance? Or, am I missing
>>> something that is a deeper problem?
>>
>> Its part of the stuff we have to figure out to make this feature work
>> again. Things changed to support multiple clusters such as moving
>> multicast transport specification at the WorldPeerGroup level which
>> were earlier at the NetPeerGroup level.
>>
>> We need Mohammed's help to figure out what is wrong in this area to
>> get further. For starters it might be a good idea to have some stack
>> traces by running crosssubnetdemo with two members each one on a
>> different network.
>>
>>>
>>> Also, Shreedhar mentioned there is an issue with setting up multiple
>>> rendezvous peers. I'm not familiar with the codebase so if someone
>>> could briefly describe what the issue is, it would help point me in
>>> the right direction.
>> Basically, we have not yet crossed the bridge with one rendezvous let
>> alone multiple. Once we address the single rendezvous, its a matter
>> of correcting the hack and doing the right thing in NetworkManager.
>>
>> Cheers
>> Shreedhar
>>>
>>> Thanks,
>>> Jim
>>>
>>>
>>>
>>>