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
>