Hello,
  The note at the end of https://docs.corda.r3.com/hot-cold-deployment.html mentions a new node configuration parameter additionalP2PAddresses. I'd like to get some clarity on it.
1. The fact that the parameter name is in plural form seems to suggest that we can have more than one back-up instance.
2. I have not tested, but should the node-info now have more than one address, one for the primary p2pAddress and the others for additionaP2PAddresses?
3. How does the additionaP2PAddresses parameter work? When another node sends a message to our node at p2pAddress, will it also send to additionaP2PAddresses?
4. Since all instances of our node share the same network drive for Artemis files, will there be any duplicates resulting from 3 above?

We'd like to explore the additionalP2PAddreses parameter so any documentation on it would be appreciated.

Thanks

\Sean

Hi Sean,

The additionalP2PAddresses was added as an alternative to load balancers in a hot-cold deployment. So it should be used only in hot-cold configurations. Because in hot-cold there is only one active instance, there is no danger of messages being sent to multiple nodes. To answer your questions:
1) in hot-cold deployments you can have as many back-ups as you can afford, but 1 is sufficient.
2) additionalP2PAddresses is required only for hot-cold nodes and only when there is no load balancer.
3) Sending node wants to open a connection to a hot-cold one. Looks up its nodeInfo and tries to connect to it using the list of p2pAddresses (primary and additional). Messages are sent to only one address (whichever is used to open the connection)
4) In hot-cold, only one instance of the node can be active at a given time, there will be no duplicates from 3.

The only information on this configuration parameter is in https://docs.corda.r3.com/hot-cold-deployment.html and https://docs.corda.r3.com/releases/master/corda-configuration-file.html?highlight=additionalp2paddresses

Hope this helps.

Bogdan

Bogdan,
  Thank you for the quick reply. To further discuss the points raised earlier -
1. For the multiple back-ups, let's look at the BCP scenario. In the primary site, there is a Hot/Code pair, and the same for BCP, for a total of 4 instances for the same node. p2pAddress is set for one instance in the primary site, and additionalP2PAddresses are for the other three instances. Forget for a moment whether it is optimal configuration or not and just focus on how it would work. Reading thru the doc, it seems the Active updates its lease per updateInterval, and the back-ups compete for the lease per waitInterval. Is it a random race among the back-ups to become the new Active after the previous Active goes down (loses its lease)? 
2. Yes, we want to explore native Corda support first before going for a third-party load balancer.
3. I am a little confused. If another node wants to initiates a flow to our node, it has 4 addresses to choose from. How will it know which one is for the current Active? You said "whichever is used to open the connection" but there is no connection yet. Please help me here.
4. Depends on how 3 works.

\Sean

One thing that slipped my mind, but additionalP2PAddresses requires min platform version to be 4 in the network. 3.0 and earlier versions can't use it.

Bogdan 

Got it. Thanks, Bogdan.
By the way, is it a way to prioritize the additionalP2PAddresses? That is, to round robin the addresses in a given order?

\Sean

Hey Sean,

No sure why you're concerned about prioritizing those addresses, but you shouldn't worry about that. Only one will(should) be usable anyway as having 2 or more nodes with the same identity active at the same time can cause all sorts of problems.

Bogdan

Hi Bogdan,
  The reason for asking for prioritization is that we want to have the back-up in the primary site scanned prior to the other back-ups in BCP, for example.
  Thanks.

\Sean

I believe there is a misunderstanding somewhere. If you're going for a hot-cold deployment as presented in the CE docs, only one node instance will be active at any given time, meaning a peer node will only be able to use one of the advertised p2p addresses to open a connection to it. In your case, if done properly, you just need to ensure that the primary node is started first for it to acquire the lock on the shared database, and the back-ups in the BCP can be set to try and start after, only becoming active if the primary fails and the lock on the database expires (see mutual exclusion configuration properties).

Bogdan

Hi Bogdan,
  You are right I misunderstood how that works. I had hoped that the back-up is always running in some kind of disabled mode - it does not process flows and/or handle messages, but it does periodically (per waitInterval) query the database to figure out if the active lease has expired to determine if it is its own turn to become the primary. That is, I had thought the back-up is a warm standby which can automatically become active shortly after the primary becomes inactive.
  After briefly testing the primary and back-up nodes with additionalP2PAddresses and mutualExclusionConfiguration, I have realized that is not the case. What actually happens is that, it seems to me, when the back-up tries to start, it first queries the db for the current lease timestamp, then it waits for a period as determined by waitInterval to query the db again to see if the timestamp has changed. If yes, the back-up will shut itself down (become cold). If no, then the back-up will start to take over as the new primary. Not sure about the exact algorithm implemented but seems to be something like that. Of course, to make it work, as documented, the primary updateInterval must be smaller that the back-up waitInterval.
  Please let me know if my new understanding is still off.
  Thanks.
\Sean