We are building a POC using Corda 4 and Springboot web server.
The POC is running in DEV MODE in our local network.
The CorDapp developed for POC has four nodes -
Provider Node
Consumer 1 Node
Consumer 2 Node
Notary Node
Every deal that takes place between the three nodes have three flows. Following are the three flows and the states:
Flow 1: Provider Node --> Consumer 1 Node
Flow 2: Consumer 1 Node --> Consumer 2 Node and Provider Node
Flow 3: Consumer 2 Node -- > Consumer 1 Node and Provider Node
I executed first two flows on July 7, 2021 -
Flow 1 from "Provider Node" to "Consumer 1 Node" and
Flow 2 from "Consumer 1 Node" to "Consumer 2 Node" and Provider Node".
Both flows were successful
I stopped the nodes after the Flow 2.
Next day, on July 8, 2021, I restarted the nodes.
I initiated Flow 3 from "Consumer 2 Node" to "Consumer 1 Node and Provider Node".
It failed
Error thrown: "The Initiator of CollectSignaturesFlow must pass in exactly the sessions required to sign the transaction."
I then initiated Flow 1 for "Provider Node" to "Consumer 1 Node"
It failed too
Error thrown: "Don't know about OU=Bank, O=MyBank, L=Houston, C=U"
Question:
What could be the reason for the above?
Should I redeploy the nodes every time after the nodes are stopped?
Since you are using a PostgreqSQL database, when you do a clean deploy, the clean command doesn't clean the postgres database, unlike h2 database.
Ideally, in production system, it is expected that you will deploy your cordapp once, later of course you can upgrade your contract, states and flows when required but you will never clean off completely the database completely.
So right now what is happening is when you deploy your cordapp for the first time, certificates are generated by the bootstrapper tool(you can find these in build/nodes/PartyA/certificates folder), they are also saved in the DB. NodeInfos are also saved here build/nodes/PartyA/
When you do a clean build, the build folder is cleaned but the database is not cleaned and gets corrupted with the new entries which also has the new entries, and the node is confused with which entry to use.
So the solution is to drop and recreate the schemas in the database as well when you do a clean deploy at the node.
your flow seems to have a mismatch between the required signers for the transactions and the required participants in the state when trying to finalize the transaction.
not sure what you mean by 'redeploy' the nodes but you don't have to restart them every time. You shouldn't have to redeploy or restart them at all ideally.
thanks and good luck!
I found that by regenerating the node infos again before restarting the nodes, I was able to execute all the flows even after stopping and starting the nodes.
Commands used for regenerating the node infos :
java -jar corda.jar clear-network-cache
java -jar corda.jar generate-node-info
These commands were run from the "/build/nodes/" folder of each node.
Related
We are building a POC using Corda 4 and Springboot web server.
The POC is running in dev mode in our local network.
The CorDapp developed for POC has four nodes -
Provider Node
Consumer 1 Node
Consumer 2 Node
Notary Node
There are three states-
State 1: NEW
State 2: APPROVED
State 3: CANCELLED
Every deal that takes place between the three nodes have three flows. Following are the three flows and the states:
Flow 1:
Provider Node --> Consumer 1 Node
Change State : NEW
Flow 2:
Consumer 1 Node --> Consumer 2 Node and Provider Node
Change State : NEW --> APPROVED
Flow 3:
Consumer 2 Node -- > Consumer 1 Node and Provider Node
State : APPROVED ---> CANCELLED
Many flows have been initiated in the CorDapp and most of them are in "APPROVED" state.
Due to new requirement, we had to change the flow definitions minutely. After changing, we created the updated CorDapp version and distributed to the four nodes.
After starting the nodes and CorDapp application, we found that the flows that are in "APPROVED" state cannot be started to change the state to "CANCELLED".
The flows are throwing error -
"The Initiator of CollectSignaturesFlow must pass in exactly the sessions required to sign the transaction."
Please note that the we are using all the correct sessions.
Question: How to update the Cordapp and continue old flows till "CANCELLED" state from "APPROVED"?
You didn't specify what the change was but my understanding is that if you change your states you have to run a schema migration. That is most likely the reason you're having this issue.
When in devmode you can pretty much just add the runSchemaMigration=true to your node config.
See example here: https://github.com/corda/cordapp-template-java/blob/release-V4/build.gradle#L103
Here's another resource that might be useful for that :https://www.corda.net/blog/upgrade-to-corda-os-46the-database-migration/
I performed below steps .
I have changed corda flow and removed this line , builder.setTimeWindow(serviceHub.clock.instant(), 30.seconds)
Now performed "gradle jar" command to build only jar and because of that created new corda app jar . e.g. old version "abc-1.1.jar" to new version "abc-1.2.jar"
Now I deployed new "abc-1.2.jar" in cordapps folder for node and restarted the node.
I am UNABLE to update old corda transactions and any update action on corda transaciton results into below error and corda node gets down after some time.
[INFO ] 2019-07-11T17:56:43,227Z [pool-12-thread-1] statemachine.FlowMonitor. -
Flow with id 90613d6f-be78-41bd-98e1-33a756c28808 has been waiting for 97904 seconds to receive messages from parties [O=BigCorporation, L=New York, C=US].
I am getting this issue and after 5 mins corda nodes stops saying heap space issue although i have given 6gb for norda node.
Please help to resolve this issue.
I am assuming that your flow is a pair of Initiator and Responder where the Responder runs on a different node. You might have updated the jar on the first node, but forgot to update it on the responder node so when your initiator is opening a FlowSession with the responder; the responder doesn't have the class for the Responding flow and Initiator is getting stuck waiting for a response. Check the logs (inside cordapps/log) of your responding node.
While upgrading from Corda 3 to Corda 4, I have an issue commiting a State to our node's ledger with only one Party. A single Party is able to create a state, notarize it, but CANNOT commit to the Corda 4 ledger without asking for an external third party.
The error Corda 4 produces (which Corda 3 did not produce) is the following:
(1) java.lang.IllegalArgumentException: A flow session for each external participant to the transaction must be provided. If you wish to continue using this insecure API then specify a target platform version of less than 4 for your CorDapp.
More specific context: Using FinalityFlow without a session yields a 'session required for external parties' error and does not complete. Adding only a session (e.g. session = initiateFlow(PartyA) ) results in an error that 'local nodes should not be included.'
Is there a workaround regarding this solution? It's important (for our use case) that a single Party can create a State and modify the State information without the involvement of other parties. Other use cases (where multiple parties are included) stem from this use case. Any guidance is greatly appreciated.
I think the error message is pretty spot on here. Just change the way you call FinalityFlow during your issuance such that it doesn’t contain a flow session to itself i.e.
return subFlow(new FinalityFlow(signedTransaction));
Although you may get a deprecation warning, in which case, do the following
return subFlow(FinalityFlow(stx, emptyList()))
I want to know if I can add pre-requisite conditions for a job based on server availability. Suppose Job J runs from job server JS, and it interacts with two other servers SERVER1 and SERVER2.
I want to configure job J such that it runs only when SERVER1 and SERVER2 are available. In case any of the two servers is down, the job should wait for servers to come back online.
I don't know if this should be a comment or an answer, but what you are looking for is not natively available within Control-M.
The simplest solution I can think for you is to configure a sleep job to run on SERVER1 and SERVER2 and have them as pre-decessors to job J. These sleep jobs will only run when the agents on SERVER1/2 are available therefore confirming server availability prior to execution of job J.
Alternatively you could write a script that loops waiting for SERVER1/2 to respond to pings then complete and configure this job as a pre-decessor to job J.
I'm still newbie in Control-M but we have implemented a solution with similar goals with a job hook to proof nodes.
Assumed, your target server (node) called JS which interacts with SERVER1 (let's call node01). Any number of servers / nodes can be added later, let's see with just one node.
Overview components:
Jobs created for monitor changes and check status while OK and NOT OK status
Quantitative resource created for each node, for example node01_run (or stacked, as you wish)
Jobs are containing quantitative resource "node01_run" with least 1 free resource
If everything ok, jobs should run as expected
If downtime is recognized, quantitative resource (QR) will be changed to 0, so affected jobs should not run,
If the node is up again, quantitative resource will be set to the original value (10, 100, 1000, ...) and the jobs should run again as usual
Job name: node01_check_resource
Job Goal ---> Check if quantitative resource already existing
Job OS Command ---> ecaqrtab LIST node01_run
Result yes ---> do nothing,
Result no ---> Job node01_create_resource, command: ecaqrtab ADD node01_run 100 (or as many as you wish)
Job name: node01_check (cyclic)
Job Goal ---> Check if node up
Job OS Command ---> As you define that you node is up: check webservice, check uptime, wmi result, ping, ...
Result up ---> rerun job in x minutes
Result no ---> go for next job
Job name: node01_up-down
Job Goal ---> Case for switching between status up and status down
Job OS Command ---> ecaqrtab UPDATE node01_run 0
On-Do action: ---> when job ended, remove condition that node01_check cannot start (as is defined as cyclic job)
Job name: node01_check_down (cyclic)
Job Goal ---> Check status while known status is down
Job OS Command ---> As defined in node01_check
Result down ---> Do nothing as job is defined as cyclic
Result up ---> Remove some contitions
Job name: node01_down-up
Job Goal ---> Switching all back to normal operation
Job OS Command ---> ecaqrtab UPDATE node01_run 100
Action ---> Add condition that node01_check can run again
You can define such job hooks for multiple nodes and you can define in each job, which nodes should be up and running (means where the quantitative resource is higher than 0). It can be monitored multiple hosts and still set the same resource - as you wish.
I hope this helps further, unless you have found a suitable solution already.
Having a question on how the build queue is configured in CC.net.
I believe we have an issue , when trying to “force” build a scheduled project, the server tries to run several builds at the same time and fails
Most of them except the one that started first.
We need to get to a state when regardless how many builds are scheduled or how many we “force” start in about the same time, all build requests are placed in to a build queue and
executed one after finishing another in the order they were placed, and no extra request are generated.
Build Failed email is sent but the build was actually successful.
In short,The erroneous email is likely due to an error in the build server’s build scheduler/queue, trying to run 2 builds instead of one when asked for a “forced” build, as a result the first one is successful and the second one fails.
How to correct/resolve this issue....?
Thanks
Nilesh
To specify your projects' queue you need to set the queue property like this :
<project name="MyFirstProject" queue="Q1" queuePriority="1">
The default value is a queue per project. If you manually set the same queue (for example Q1) for all you project then, you will have a unique queue.
As for the queuePriority, the project (not yet started) in the queue are ordonned by queuePriority, low queuePriority projects start first.
It's all described in the cc net documentation which is now offline due to a problem at sourceforge.