We need to change our Corda Network infrastructure. Currently we are working with one network map, three notaries (RAFT) and four additional nodes.
We will replace our network map and one notary server (notaryCluster one) with new servers.
Our plan is to perform following steps:
1. Stop all Nodes
2. Change all node.conf files needed to point to new networkmap and new notary
3. Deploy Networkmap and Notary service in new servers from scratch (not reusing data from old notary and network map)
4. Start new network map, start new notary servers, and rest of nodes (not old network and notary)
Is this process correct to ensure existing transactions will remain in the systems and will be able to work with them?
Thanks!!
There are several things you need to consider
- Stop all Nodes
You need to consider any flows that are currently in-flight to perform a clean shutdown of the node.
Version 3.1 of Corda adds a "Draining mode" feature, through which:
Commands requiring to start new flows through RPC will be rejected.
Scheduled flows due will be ignored.
Initial P2P session messages will not be processed, meaning peers will not be able to initiate new flows involving the node.
- Deploy Network map and Notary service in new servers from scratch (not reusing data from old notary and network map)
You would want to keep data from the old notary, else the notary would lose track of states that have been consumed, and the network would lose the guarantee of preventing double spends
Related
Can I create a corda node basically I don't want to store any state. Purpose of this nodes is to handle communication between nodes in the same network and outside network.
I would not recommend you to do this. The whole idea of a Corda and having corda node's communication is to make sure that all parties have the same view of database, to make sure that "what you see is what I see".
If they aren't going to be any states, it doesn't make sense to put in the efforts to setup a node, you might simply have a simple database or a queue in between instead.
In our Corda network we work with Accounts. We have a network with well-defined nodes.
To show the problem, imagine 3 nodes, PartyA, PartyB and Notary.
We created the accounts (AccountA for example) on PartyA. We have flows that can be executed at PartyB that has AccountA as a participant in the transaction.
Now imagine that PartyA is down for any reason, or communication between nodes is not available.
When I request a new AccountA key for PartyA, the flow gets stuck trying to communicate and does not return any exception. This happens in any situation that tries to communicate with another node, when running a CollectSignaturesFlow or ShareStateAndSyncAccounts to share account states for example.
The question is, is there any configuration or mechanism to return an exception in those cases where it is unable to communicate with another node?
Timeouts can be handled differently depending on where you need to manage it.
There is the flowTimeout:
When a flow implementing the TimedFlow interface and setting the
isTimeoutEnabled flag does not complete within a defined elapsed time,
it is restarted from the initial checkpoint.
Currently only used for notarisation requests with clustered notaries
Or otherwise it can be done programmatically in your flow. I suggest you to take a look to this part of the Corda documentation (Concurrency, Locking and Waiting) where there are many suggestions that you could try to implement.
I am trying to run Example Cordapp in two different VMs. With Notary and PartyC in 1st server and PartyA and PartyB in 2nd server.
I followed the steps here, Corda nodes: how to connect two independent pc as two nodes
In the conf file of,
Notary and PartyC - I have edited the P2P address
PartyA and PartyB - I have edited the P2P address
With the above conf files, I ran the Network Bootstrapper jar in server 1 and copied the folders PartyA and PartyB in another cordapp example to server 2 and started the Notary and Parties 1 by 1 respectively in the corresponding VMs.
All nodes started succesfully and when I try to execute a IOU flow from PartyC(in server 1) to PartyB(in server2), it is pausing at Collecting counterparties signature step without proceeding further. Below is what I see in PartyC's Console,
enter image description here
The flow getting stuck in CollectSignatureFlow means the initiating node is not able to get a response from the counterparty node.
The CollectSignatureFlow internally establishes a session with the counterparty node and shares the transaction data to get the signature.
Since you have nodes in separate machines, they are probably not able to see each other. Generally, if nodes are hosted in a separate VM, the VM's must have public IPs or must be in a network where they are able to see each other.
I have set up Akka.net actors running inside an ASP.net application to handle some asynchronous & lightweight procedures. I'm wondering how Akka scales when I scale out the website on Azure. Let's say that in code I have a single actor to process messages of type FooBar. When I have two instances of the website, is there still a single actor or are there now two actors?
By default, whenever you'll call ActorOf method, you'll order creation of a new actor instance. If you'll call that in two actor systems, you'll end up with two separate actors, having the same relative paths inside their systems, but different global addresses.
There are several ways to share an information about actors between actor systems:
When using Akka.Remote you can call actors living on another actor system given their addresses or IActorRefs. Requirements:
You must know the path to a given actor.
You must know the actual address (URL or IP) of an actor system, on which that actor lives.
Both actor systems must be able to communicate via TCP between actor system (i.e. open ports on firewall).
When using Akka.Cluster actor systems (also known as nodes) can form a cluster. They will exchange information about their localization in the network, track incoming nodes and eventually detect a dead or unreachable ones. On top of it, you can use higher level components i.e. cluster routers. Requirements:
Every node must be able to open TCP channel to every other (so again, firewalls etc.)
A new incoming node must know at least one node that is already part of the cluster. This is easily achievable as part of the pattern known as lighthouse or via plugins and 3rd party services like consul.
All nodes must have the same name.
Finally, when using cluster configuration you can make use of Akka.Cluster.Sharding - it's essentially a higher level abstraction over actor's location inside the cluster. When using it, you don't need to explicitly tell, where to find or when to create an actor. Instead, all you need is a unique actor identifier. When sending a message to such actor, it will be created ad-hoc somewhere in the cluster if it didn't exist before, and rebalanced to equally spread the workload in cluster. This plugin also handles all logic associated with routing the message to that actor.
In my scenario, Transaction is between two nodes in two different Machines. Currently am using a controller in Machine A which acts as a notary as well. Can i use two controllers one in each machine?
As discussed here: Corda Controller Node, Corda has no concept of a "controller" node.
Up until Corda 2, each network had a single network map node, no matter how many machines were involved. Each node's configuration file would point to this network map node, using its IP address and port number.
In Corda 3, the network map node was replaced with a server distributing network map files. Details about how to deploy a network across machines in Corda 3 can be found here: https://docs.corda.net/tutorial-cordapp.html#running-nodes-across-machines.
yes, you can setup your case. NotaryChangeFlow (initiating), which should be used to change a state’s notary.