This question already has an answer here:
What are the cases where a TX is not sent to the Notary Service?
(1 answer)
Closed 4 years ago.
Just ran my node directly:
java -jar corda.jar
But did not run the notary. Ran a flow that creates an output and calls FinalizeFlow. Completed successfully, then I was able to query the vault for the new state. This should not have happened since the Notary did not notarize the transaction?
A transaction is only sent to the notary for notarisation as part of FinalityFlow if:
It has one or more inputs, and/or...
It has a timestamp
If your transaction does not meet either of these conditions, it will not be sent to the notary, explaining the behaviour you saw above.
Related
Network:
PartyA, PartyB, PartyC, Notary
Scenario:
PartyB’s node is put into draining mode.
PartyA performs a transaction where PartyB and PartyC are
participants (not signers)
Outcome:
PartyA completes the transaction, gets the notary’s signature and
saves the state in its vault.
PartyB will not be informed of transaction (expected)
PartyC will not be informed of the transaction (surprise!)
Learning:
I assume because PartyC is listed after PartyB in getParticipants() it has to wait until PartyB is back online before it will receive the transaction. This is unfortunate because PartyC gets punished because PartyB’s node is down.
Question:
Is this just a limitation of the open source version of Corda? Would Corda Enterprise behave the same way?
Thoughts:
It may be necessary to clearly inform the users of your CorDapp about this phenomenon because it creates a condition of asymmetric information that is caused by some other node on the network.
It is a limitation of Corda Open Source. The FinalityFlow of Corda Enterprise (up until 4.x) sends the transaction - after notarisation - to all the peers and resolution is performed in parallel for increased performance. In Corda Open Source it is done in sequence.
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 set up a network with 2 normal Node (NodeA and NodeB) and 1 Notary. If NodeA has shut down and lose apart of its database (about current states), how can We ensure that the network may run as well. And how does NodeA restore this data that loss? (Can Enterprise Corda Version help me in this case?)
When a database admin deletes your data, Corda will not be able to help you. You are responsible for your own database. You need to ensure that only authorized parties have permissions to access the database.
Let's say that PartyA now does not have latest states/ data for your custom tables. In this scenario, PartyA can request PartyB for this missing state if PartyB was also a participant to the state. It depends on PartyB whether to share this state to PartyA.
There is a built in flow to send the state from one party to other
SendStateAndRefFlow(otherSideSession: FlowSession, stateAndRefs: List<StateAndRef<*>>)
I'm searching for a high-available SQL solution! One of the articles that I read was about "virtually synchronized" in Galera Cluster: https://www.percona.com/blog/2012/11/20/understanding-multi-node-writing-conflict-metrics-in-percona-xtradb-cluster-and-galera/
He says
When the writeset is actually applied on a given node, any locking
conflicts it detects with open (not-yet-committed) transactions on
that node cause that open transaction to get rolled back.
and
Writesets being applied by replication threads always win
What will happen if the WriteSet conflicts with a committed transaction?
He also says:
Writesets are then “certified” on every node (in order).
How does Galera Cluster make WriteSets ordered over a cluster? Is there any hidden master node who make WriteSets ordered; something like Zookeeper? or what?
This is for the second question (about how Galera orders the writesets).
Galera implements Extended Virtual Synchrony (EVS) based on the Totem protocol. The Totem protocol implements a form of token passing, where only the node with the token is allowed to send out new requests (as I understand it). So the writes are ordered since only one node at a time has the token.
For the academic background, you can look at these:
The Totem Single-Ring Ordering and Membership Protocol
The database state machine and group communication issues
(This Answer does not directly tackle your Question, but it may give you confidence that Galera is 'good'.)
In Galera (PXC, etc), there are two general times when a transaction can fail.
On the node where the transaction is being run, the actions are compared to what is currently running on the same node. If there is a conflict, either one of the transactions is stalled (think innodb_lock_wait_timeout) or is deadlocked (and rolled back).
At COMMIT time, info is sent to all the other nodes; they check your transaction against anything on the node or pending (in gcache). If there is a conflict, a message is sent back saying that there would be trouble. So, the originating node has the COMMIT fail. For this reason, you must check for errors even on the COMMIT statement.
As with single-node systems, a deadlock is usually resolved by replaying the entire transaction.
In the case of autocommit, there is a small, configurable, number of retries, after which the statement will fail. So, again, check for errors. However, since a retry has already been tried, you may want to abort the program.
Currently (in my opinion) Galera, with at least 3 nodes in at least 3 different physical locations, is the best available HA solution for MySQL. It can effectively survive any single-point-of-failure. (Group Replication / InnoDB Cluster, from Oracle, is coming soon, and is very promising.)
One thing to note is that the "critical read" problem has a solution in Galera, but you have to take action. See wsrep_sync_wait. (As of this writing, InnoDB Cluster has no solution.)
See http://mysql.rjweb.org/doc.php/galera for tips (some of which are included above) on coding differences when moving to PXC/Galera.