https://docs.corda.net/changelog.html#version-3-0 states that "an H2 database instance of Corda 1.0 and 2.0 cannot be reused for Corda 3.0". Does this means that if I have a Cordapp running Corda 2.0 and I want to upgrade my CorDapp to Corda 3.0, I need to discard all my node's stored information from Corda 2.0, start fresh and re-run all the transactions that were processed before accepting new ones?
Let's take an example. I have a Corda 2.0 CorDapp to record cash-in and cash-out. This CorDapp has been operating for a while, with 10k transactions stored in the vault already. And let's say that there are 50 new transactions a day.
Suppose that on March 1st, Alice deposits $30. On March 2nd, Alice withdraws $20. She therefore only has $10 available.
If I want to upgrade my Cordapp to Corda 3.0 on March 14th, I'll need to discard the stored data from my Corda 2.0 Cordapp (persistence.mv.db, etc.) and re-run those 10k transactions in Corda 3.0 before allowing Alice to do any new deposits/withdrawals (since I can't allow Alice to have anything different than $10). Is my understanding correct?
That's correct. Corda 1.0 guaranteed API stability (meaning that your CorDapps will not break from one release of Corda to the next), but it did not guarantee wire stability. This means that data created using Corda 2.0 or earlier will not necessarily be readable by Corda 3.0.
Corda 3.0 does guarantee wire stability, meaning that data created from Corda 3.0 onwards will be readable by future versions, and that nodes running different Corda versions (3.0+) will be able to communicate.
Your best option in migrating from Corda 2.0 to Corda 3.0 is indeed to rerun all the transactions on Corda 3.0, and only run new transactions once that process is complete.
Related
Background:
We are trying to load data in our Custom CorDapp(Corda-3.1) using jmeter.
Our CorDapp is distributed across Six nodes(Three Parties, Two Notaries and One Oracle).
The Flow being executed in order to load data is having very minimal business logic, has three participants and requires two parties to sign the transaction.
Below is the environment, configuration and test details:
Server: Ubuntu 16.04
Ram: 8GB
Memory allocation to Corda.jar: 4GB
Memory allocation to Corda-webserver.jar : 1GB
JMeter Configuration- Threads(Users): 20 (1 transaction per second per thread)
Result:
Node B crashed after approx 21000 successful transactions(in approximately 3 hours and 30 mins) with "java.lang.OutOfMemoryError: Java heap space". After some time other nodes crashed due to continuous "handshake error" with Node B.
We analyzed heap dump using Eclipse MAT and found out that more than 21000 instances of hibernate SessionFactoryImpl were created which occupied more than 85% of the memory on Node B.
We need to understand why Corda network is creating so many objects and persisting them in memory.
We are continuing our investigation as we are not 100% sure if this is entirely Corda bug.
Solution to the problem is critical in our pursuit to continue further tests.
Note - We have more details about our investigation but we are unable to attach them here but can send over email.
If you're developing in Java, it is likely that the issue you're encountering has already been fixed by https://r3-cev.atlassian.net/browse/CORDA-1411
The fix is not available in Corda 3.1 yet, but the JIRA ticket provides a workaround. You need to override equals and hashCode on any subclasses of MappedSchema that you've defined. This should fix the issue you're observing.
Background-
I am extremely new to CORDA and Blockchain Platform. In the past few months i have had my share of experience working on a small project on Ethereum as platform. Ethereum blockchain was leveraged as ledger to mark Transaction as a proof of existence. It means for some action (success/failure) we have marked respective transaction on Blockchain. We may consider it as a proof of concept to show knowledge of interaction with nodes running on Ethereum Blockchain.
Infrastructure - Node.js web services, two ethereum (PoA) nodes
Question-
I would now like to port this running example on to CORDA blockchain. How would i achieve this with bare minimum changes. That means if i have a Corda network with two nodes running on my system and i want my web services to connect to one or both of the nodes and save the transaction (in its state). I understand that this certainly is not what CORDA might be meant for. Consider this question as my first step to interact with CORDA from Node.js web services.
Any inputs highly appreciated.
I recommend you go through the documentation first. your Tx will be a state. you need to build contracts and flows for a Tx to happen. Tx will happen using flows which will be initiated using Crash Shell or RPC Client. AFAIK, this client is in Kotlin or Java. so you'll have to create a JAVA or Kotlin application to instantiate this client. now in the Java application, you'll have to expose rest endpoints to communicate with the client which will initiate your flows. you can call these rest endpoints from your node application. All this has to be created in CodaApp. This is the bare minimum.
I just found there is a library.
look at this: https://gitlab.com/bluebank/braid
This can help you.
We need to save about 10 millions transactions (each transaction will save one HASH of a electronic contract) per day and keep them for 3 years at least.
Because Corda can only support h2 database currently, we want to know if Corda can not support saving so many tranactions due to the limit of the database or somethig else?
The open source version of Corda was originally coded against the h2 database. We have had community contributions which enable Corda to run against postgres - although please be aware that this is a contribution so we run all of our testing against h2 and so we may not immediately pick up issues when running against the postgres database platform.
However, "R3 Corda" will support a variety of fully pluggable databases. If you intend to use Corda in a production environment, then I would recommend you use this version for deployment. Any code written against O/S Corda (or running on an O/S Corda node) will be fully compatible with the R3 Corda platform.
I would like to understand if it is possible to scale a Corda node out horizontally and how this would work.
I have read that the message broker is planned to be separated from the Corda node which I guess would allow for horizontal scaling. Would the message broker be the entity that is identified by the network map service or would each of the underlying Corda nodes still have their own separate network identity and vaults?
My question is for v1 open source, Corda enterprise or if it is planned for future releases.
We have some work in progress here related to the flows and we'll talk more about this in the very near future. But in the current open source 1.0 branch it would be a scale up model. You could scale out the Artemis MQ however. But it would be a single node for Corda at the moment.
I have an activeMQ network with 2 instances. Those 2 instances are running 5.5 version of activeMQ. I want to add a new server in 5.9 version. Is this feasible? What should I have in mind? Any gotchas?
Thanks.
We don't test the network of brokers between versions. It may work but we encourage users to upgrade all their brokers to the latest release once the messages contained in those broker's stores have been migrated to a new broker. You can do this by networking an older broker to a newer one and then creating a subscription on any destination that has messages on the old broker on the new one and letting the demand drain the old broker.