Hello. Thanks for the reply. I am using ChannelEventHub. I found the discussion/recommendations for strategies surrounding how to detect which events have been missed in the link I provided (the older

Sample of using a block listener to save the blocks https://github.com/hyperledger/fabric-samples/blob/release-1.4/off_chain_data/README.md

The fabric event service is no longer supported and the 'EventHub.js' has been removed from the NodeSDK. To use the new fabric channel event service on a peer use the new 'ChannelEventHub.js'.

Hello Labib Farag, Thanks for the response. That certainly provides a standardized interface for solving the problem. However, if you will notice, the disclaimer states: Disclaimer Checkpointing in

did you checked this which is module for replaying missed events emitted by peers https://fabric-sdk-node.github.io/release-1.4/tutorial-event-checkpointer.html

Hi team, I am trying to fix orderer panic; this happens repeatedly every 12 hours. Here is orderer log. ============================= ... 2019-09-09 03:57:35.761 KST [orderer.common.server] Start ->

Hello HyperLedger Fabric community, I am working on implementing an application that receives chaincode events of interest (via a regular expression match on the event name) and then places those

No, that's right, for a minimal test case I only changed the class name. In the original attempt I changed both and got the same behaviour.

It seems you didn't change the contract name in package.json papercontract as the contract installed on peer with details name: papercontract, Version: 0

PS: A simpler and more easily reproducible test is now available in Stack Overflow

I am trying to adapt the commercial paper tutorial to a custom contract, and cannot instantiate it. In commercial-paper/organization/magnetocorp/contract, I updated: package.json with a new name,

Hi, Thanks a lot and look forward to the blog update. And speaking of the scalability issue, It appears that that it would not actually be an issue because a single VM would be good

Hi, Right, the Accenture blog post explains a lot about our GitHub repo. But it’s not up to date, much more functionality added to repo after blog is written. However, motivation benefits etc

HI, The two links below actually explain the same method right? https://github.com/APGGroeiFabriek/PIVT/blob/master/README.md#backup-restore

The different revs does not indicate a data correctness problem. You may see this for example if one peer crashes while writing to state database. When the peer is restarted it will detect that it was

Hi to all, currently using a network with Kafka ordering service, with 2 orderers and 4 peers. Checking data from the couchdb mychannel_mychannel database on all peers i can see some differences on

Hello All, We will restart the documentation workgroup on Friday, 6 September after a few weeks break due to travel and summer vacations. As usual, we run the meeting twice during the day to make it

No, the timestamp has never been used to order results, or in any other regard within Fabric. There has been a recent improvement in GetHistoryForKey though... this text will appear in the upcoming

Hey Dave, Good to know the timestamp isn't used anywhere else. However, it is used for determining the order of transactions returned by the GetHistoryForKey iterator, correct? Or at least, in our

Fabric intentionally doesn't use the timestamp from the submitting application for anything, therefore there are no impacts with respect to Fabric processing. The timestamp is not intended to be a