Missed some lines in my response. See below in highlight.
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 numbers
> 605 through 608
worldGroupConfig.setTcpPort(Integer.parseInt(myPort));
worldGroupConfig.setTcpStartPort(Integer.parseInt(myPort));
worldGroupConfig.setTcpEndPort(Integer.parseInt(myPort));
>
>
>> 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
>