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.
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.
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
b. JxtaConfigConstants .VIRTUAL_MULTICAST_URI_LIST - sets the the
list rendezvous seed URIs.
c. A parameter to determine if multicast is enabled. If disabled, the
rendezvous seed list must contain at least one value
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.
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...
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
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>