refactor(ledger-connector-corda): add startMonitor features #1610

takeutak · 2021-11-30T06:07:46Z

Is your feature request related to a problem? Please describe.
On the current codes, some ledger-connectors (besu, quorum, corda, ...) does not have common API for monitoring block data on connected ledgers.
Corda has no block structure, but if some numbers of transactions are assumed as blocks, this feature can be developed.

This feature was already developed in cmd-socket-server and related ledger-connectors, but in case of merging those codes, we need to enhance the range.

Describe the solution you'd like
Add startMonitor feature to the above ledger-connector

EPIC
#1611

petermetz · 2021-12-06T16:20:15Z

Applies to Corda v4.8

outSH · 2022-03-24T09:36:06Z

@petermetz I have some questions regarding corda connector and possible monitoring implementation, could you answer them please?

Does BLP (apiClient) ever need to call kotlin server directly? There're tests for that, but my assumption is that on production kotlin server could be strictly separated from the rest of the network.
Why there's a single API for both kotlin and typescript services? They'll either diverge along the way, or one of the services will be obsolete, or am I missing something?
Can we add watchBlocks endpoint to typescript component only, and different monitoring implementation endpoints on kotlin server (startMonitor, stopMonitor, getBlocks)?

petermetz · 2022-03-29T04:30:55Z

@outSH Sorry for the slow responses.

Does BLP (apiClient) ever need to call kotlin server directly?

If the application is designed that way then yes. It is possible to design the application in such a way that the answer is no, but that limits certain options of course.

There're tests for that, but my assumption is that on production kotlin server could be strictly separated from the rest of the network.

You could deploy it on a separate network if you wanted to, yes.

Why there's a single API for both kotlin and typescript services? They'll either diverge along the way, or one of the services will be obsolete, or am I missing something?

The Typescript code is being redone to be the code for Corda v5. You just cannot see this on main yet but there's been a PR open for quite some time that we need to finalize and then merge (and then if you read the code on main it will make much more sense)

Can we add watchBlocks endpoint to typescript component only, and different monitoring implementation endpoints on kotlin server (startMonitor, stopMonitor, getBlocks)?

If you'd like to, sure thing. Just keep in mind that Kotlin server is for Corda v4 and the Typescript code of the connector is for Corda v5 (in the near future as soon as we can finalize the PR for it)

outSH · 2022-03-29T07:28:21Z

@petermetz The PR you have in mind is #1860?

If you'd like to, sure thing. Just keep in mind that Kotlin server is for Corda v4 and the Typescript code of the connector is for Corda v5 (in the near future as soon as we can finalize the PR for it)

Judging from that PR connector will support both corda v4 and v5, so adding watchBlocks there makes sense I think :)

Add new endpoints to corda kotlin server used to start and stop monitoring, and get/clean state changes from its internal buffer. Add reactive watchBlocksV1 that polls kotlin server and reports new transactions asynchronously. Add CordaApiClient support to VerifierClient. Add functional test for both monitoring interfaces. Update corda setup in corda-all-in-one to newer version. Closes: hyperledger-cacti#1610 Signed-off-by: Michal Bajer <[email protected]>

Add new endpoints to corda kotlin server used to start and stop monitoring, and get/clean state changes from its internal buffer. Monitoring session is started separately for each client, each client can monitor many corda states. Clients that are not active for specified amount of time are removed. Implementation uses transaction queues that are polled periodically by the client, instead of socketio-based solution because we want to minimize probability of losing a transaction from corda. This can happen when WS connection is disconnected, for instance. With transaction queue on the connector, and explicit get/remove calls from the client, we have greater control over what transactions are delivered to the client code. Also, setting up socketio on spring boot seems overly complicated and would obscurificate the implementation. Add reactive watchBlocksV1 that polls kotlin server and reports new transactions asynchronously. Add CordaApiClient support to VerifierClient. Add functional test for both monitoring interfaces. Update corda setup in corda-all-in-one to newer version. Closes: hyperledger-cacti#1610 Signed-off-by: michal.bajer <[email protected]>

Add new endpoints to corda kotlin server used to start and stop monitoring, and get/clean state changes from its internal buffer. Monitoring session is started separately for each client, each client can monitor many corda states. Clients that are not active for specified amount of time are removed. Implementation uses transaction queues that are polled periodically by the client, instead of socketio-based solution because we want to minimize probability of losing a transaction from corda. This can happen when WS connection is disconnected, for instance. With transaction queue on the connector, and explicit get/remove calls from the client, we have greater control over what transactions are delivered to the client code. Also, setting up socketio on spring boot seems overly complicated and would obscurificate the implementation. Add reactive watchBlocksV1 that polls kotlin server and reports new transactions asynchronously. Add CordaApiClient support to VerifierClient. Add functional test for both monitoring interfaces. Update corda setup in corda-all-in-one to newer version. Closes: hyperledger-cacti#1610 Signed-off-by: Michal Bajer <[email protected]>

Add new endpoints to corda kotlin server used to start and stop monitoring, and get/clean state changes from its internal buffer. Monitoring session is started separately for each client, each client can monitor many corda states. Clients that are not active for specified amount of time are removed. Implementation uses transaction queues that are polled periodically by the client, instead of socketio-based solution because we want to minimize probability of losing a transaction from corda. This can happen when WS connection is disconnected, for instance. With transaction queue on the connector, and explicit get/remove calls from the client, we have greater control over what transactions are delivered to the client code. Also, setting up socketio on spring boot seems overly complicated and would obscurificate the implementation. Add reactive watchBlocksV1 that polls kotlin server and reports new transactions asynchronously. Add CordaApiClient support to VerifierClient. Add functional test for both monitoring interfaces. Update corda setup in corda-all-in-one to newer version. Closes: #1610 Signed-off-by: Michal Bajer <[email protected]>

Add new endpoints to corda kotlin server used to start and stop monitoring, and get/clean state changes from its internal buffer. Monitoring session is started separately for each client, each client can monitor many corda states. Clients that are not active for specified amount of time are removed. Implementation uses transaction queues that are polled periodically by the client, instead of socketio-based solution because we want to minimize probability of losing a transaction from corda. This can happen when WS connection is disconnected, for instance. With transaction queue on the connector, and explicit get/remove calls from the client, we have greater control over what transactions are delivered to the client code. Also, setting up socketio on spring boot seems overly complicated and would obscurificate the implementation. Add reactive watchBlocksV1 that polls kotlin server and reports new transactions asynchronously. Add CordaApiClient support to VerifierClient. Add functional test for both monitoring interfaces. Update corda setup in corda-all-in-one to newer version. Closes: hyperledger-cacti#1610 Signed-off-by: Michal Bajer <[email protected]>

takeutak added the enhancement New feature or request label Nov 30, 2021

petermetz assigned takeutak Dec 6, 2021

outSH mentioned this issue Mar 31, 2022

feat(corda4): implement monitoring of state changes #1956

Merged

petermetz closed this as completed in #1956 Apr 26, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

refactor(ledger-connector-corda): add startMonitor features #1610

refactor(ledger-connector-corda): add startMonitor features #1610

takeutak commented Nov 30, 2021 •

edited

Loading

petermetz commented Dec 6, 2021

outSH commented Mar 24, 2022

petermetz commented Mar 29, 2022 •

edited

Loading

outSH commented Mar 29, 2022 •

edited

Loading

refactor(ledger-connector-corda): add startMonitor features #1610

refactor(ledger-connector-corda): add startMonitor features #1610

Comments

takeutak commented Nov 30, 2021 • edited Loading

petermetz commented Dec 6, 2021

outSH commented Mar 24, 2022

petermetz commented Mar 29, 2022 • edited Loading

outSH commented Mar 29, 2022 • edited Loading

takeutak commented Nov 30, 2021 •

edited

Loading

petermetz commented Mar 29, 2022 •

edited

Loading

outSH commented Mar 29, 2022 •

edited

Loading