Date   

Newly added peer getting online/offline messages along with old non-anchor peers #hyperledger-fabric #grpc #tls

chintanr97@...
 

I am encountering the following scenario: 
  1. I am running a network on multiple hosts.
  2. The network has one Orderer Organization (3 orderers in RAFT mode) and 1 Peer organization (2 Peers). Both having different Fabric CA instances.
  3. The application channel is created using all the orderers. Peer organization is added to consortium and the application channel. 
  4. Both the peers join the channel. I have configured Peer1.PeerOrg to be an anchor peer. 
  5. I install and instantiate chaincode. Invoke and query them multiple times.
  6. Create a new peer node MSP with PeerOrg CA.
  7. Start the new peer node and join the channel.
  8. Upon successful sync with the channel, the new peer node keeps getting logs that state "Membership view changed. Peers went online/offline". 
The following warning messages are accompanied by ERR message: "TLS handshake failed with error remote error: tls: bad certificate server=PeerServer".
The same set of ERR and WARN messages flood the logs of this new peer as well as of Peer2.PeerOrg (the non-anchor peer). 

So, now I switched anchor peer endpoint in application channel to Peer2.PeerOrg endpoint. Now again the new peer and Peer1.PeerOrg logs are flooded by above messages. 

At this stage, I remove anchor peers completely. Restart the peer nodes: Peer3.PeerOrg and Peer1.PeerOrg. No ERR or WARN messages occur now.

NOTE: All peers can communicate through one another by external endpoints. TLS certificates of all the peer nodes have been validated and are configured with correct DNS Alt Names. 

Can anyone please tell why this issue occurs?


Re: Adding a peer node when no genesis block orderer exist in the channel #fabric-orderer #raft #hyperledger-fabric

chintanr97@...
 

@Yacov, I would like to highlight that why aren't we making using of peer CLI command for this? I mean to say that in "peer channel join" command we have an option of specifying the orderer endpoint, right? We should just extend that to be used in the scenario where peer cannot pull blocks from genesis block orderers. Specifying "-o" argument should make the peer pull channel blocks from the specified endpoint instead of looking into config block.

You can run the peer channel join command like follows:
peer channel join -b mychannel.block -o orderer4.example.com --tls --cafile <ordererTLSCAFile>

The benefit would be: 
  1. The change in core.yaml is permanent like you explained on my JIRA. This feature would be dynamic in nature.
  2. Already running peers could join newer channels dynamically. 
Currently, I tried implementing above feature but peer node does respect the "-o" argument (and yet we have it in the "peer" binary commands). If we are using it in other operations like "invoke" then we should allow this command to run parallel to that, giving a more dynamic nature, instead of making using of core.yaml. 

Please let me know your thoughts on this.


ERR! 404 Not Found - GET https://registry.npmjs.org/fabric-chaincode-api - Not found #fabric-sdk-node

Magno Alves Cavalcante
 

Hello All!

I wrote my chaincode using Node.js API, and now I'm trying to instantiate.

image: hyperledger/fabric-peer:1.4.5

My package.json has the follow source:
// -------------------
{
"name": "democontract",
"version": "1.0.0",
"description": "Document Contract",
"main": "index.js",
"engines": {
"node": ">=8.4.0",
"npm": ">=5.3.0"
},
"scripts": {
"lint": "eslint .",
"pretest": "npm run lint",
"start": "fabric-chaincode-node start",
"mocha": "mocha test --recursive"
},
"engine-strict": true,
"license": "Apache-2.0",
"private": true,
"dependencies": {
"mkdirp": ">=0.5.5",
"openpgp": "^4.10.0",
"fabric-chaincode-api": "^1.4.0",
"fabric-shim": "^1.4.0"
},
"devDependencies": {
"chai": "^4.1.2",
"chai-as-promised": "^7.1.1",
"eslint": "^4.19.1",
"mocha": "^5.2.0",
"nyc": "^12.0.2",
"sinon": "^6.0.0",
"sinon-chai": "^3.2.0"
}
}
// -------------------

But when I call in CLI container to instantiate the chaincode (democontract):
// -------------------
peer chaincode instantiate -C $CHANNELNAME -n $CHCODENAME -v $CHCODEVERSION -o $ORDERERNAME \
-c '{"Args":["ContractDocument:instantiate"]}' \
-P "OR('OrdererMSP.admin','Org1MSP.admin','Org1MSP.peer','Org1MSP.member')" \
--tls --cafile $ORDERER_TLSCACERT --tlsRootCertFiles $CORE_PEER_TLS_ROOTCERT_FILE
// -------------------

I'm receing the follow ERROR at PEER container, and chaincode failed to instantiate.

I don't know how to get out of this error condition.
Please, may you help me?

// -------------------
[endorser] SimulateProposal -> ERRO 050 [devchannel][bef25398] failed to invoke chaincode name:"lscc" , error: Failed to generate platform-specific docker build: Error returned from build: 1 "npm WARN deprecated mkdirp@0.5.1: Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
npm WARN deprecated circular-json@0.3.3: CircularJSON is in maintenance only, flatted is its successor.
npm WARN deprecated resolve-url@0.2.1: https://github.com/lydell/resolve-url#deprecated
npm WARN deprecated urix@0.1.0: Please see https://github.com/lydell/urix#deprecated
npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/fabric-chaincode-api - Not found
npm ERR! 404
npm ERR! 404 'fabric-chaincode-api@^1.4.0' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404 It was specified as a dependency of 'output'
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2020-05-18T19_31_20_461Z-debug.log
"
error starting container
error starting container
// -------------------

---
Regards,
Magno A. Cavalcante


Re: Confusion related to env variable ORDERER_TLS_CA

Gari Singh <garis@...>
 

You are really asking two separate questions here.



1. ORDERER_GENERAL_TLS_ROOTCAS

Strictly speaking, you don't necessarily have to set this at all. This config parameter is used by the orderer to determine which certificates to trust when acting as a client communicating with TLS enabled endpoints. It's really not needed as the orderer also gets this same information from channel config blocks as well.


2. "So while TLSing via Peer ..."

I assume here you are really talking about the various peer CLI commands which happen to communicate with ordering nodes (as well as peer nodes). Commands such as "peer channel create|fetch|update ..." and "peer chaincode instantiate|invoke|query" not only communicate with peers, but they also directly communicate with ordering nodes. In this case, the "peer" command is actually acting as a client. If TLS is enabled, you need to tell the peer CLI which certificates to "trust". You specify this via the "--cafile" flag when using the various peer CLI commands mentioned previously.

When the peer is running as a "server" process (meaning as a real peer), it actually uses information from channel config blocks to figure out which TLS certificates to trust.





-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: "Abhijeet Bhowmik"<abhijeet@...>
From: jongkwon.lee@...
Sent by: fabric@...
Date: 05/18/2020 03:37AM
Cc: <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Confusion related to env variable ORDERER_TLS_CA

You can find the basics of gPRC TLS authentication here: https://blog.gopheracademy.com/advent-2019/go-grps-and-tls/
The article does not cover the usage of multiple CAs, but we could suppose it would handle the intermediate CAs.

I'd like to add that peers do not connect to orderers in general use cases. Client apps connect to orderers to submit transactions. Clients may need to know the ca cert file, but you also can use service discovery instead of setting the ca cert path manually.

​-----Original Message-----
From: "Abhijeet Bhowmik"<abhijeet@...>
To: <fabric@...>;
Cc:
Sent: 2020. 5. 15. (금) 15:57 (GMT+09:00)
Subject: [Hyperledger Fabric] Confusion related to env variable ORDERER_TLS_CA


Hello wonderful people,

I hope all are doing well. As a beginner, I have a confusion that came to me while writing docker-compose files to build my own network. There is an env variable in the orderer section
'
- ORDERER_GENERAL_TLS_ROOTCAS=[/etc/hyperledger/tls/orderer/ca.crt]'

So while TLSing via Peer, I have been told to use orderer's /tls/ca.crt. That's where my confusion lies. If anyways we are gonna use orderer's tls/ca.crt, what's the purpose of having value of ORDERER_GENERAL_TLS_ROOTCAS as array. What other values could I mention there. And what will be their significance? Ideally while TLSing between Server-client, Server presents it's certificate (with public key) during the request and the client doesn't have it pre hand. So if we go by that scenario, maybe either the orderer should present it's cert during the request or else there must be a way that we can use peer side artifacts to do the TLS. I see no point in copying orderer's tls/ca.crt to every peer manually.

Definitely I could be wrong. I will be more than happy if someone throws some light on this. Looking forward to it.

Thanks and Regards
Abhijeet Bhowmik


Re: Adding a peer node when no genesis block orderer exist in the channel #fabric-orderer #raft #hyperledger-fabric

Yacov
 

Read this JIRA https://jira.hyperledger.org/browse/FAB-5288



From:        chintanr97@...
To:        fabric@...
Date:        05/18/2020 09:37 AM
Subject:        [EXTERNAL] [Hyperledger Fabric] Adding a peer node when no genesis block orderer exist in the channel #fabric-orderer #raft #hyperledger-fabric
Sent by:        fabric@...




The peer fails to join the channel in the following scenario:
1.        A channel was created by the Orderer Organization (running 3 orderers in RAFT mode).
2.        A peer organization was added (let's say with 3 peers). Chaincodes were installed, instantiated and invoked several times.
3.        Over channel lifetime, the orderer nodes in channel were modified to the extent that no channel genesis block orderers existed in the channel any longer.
4.        A requirement occurred to add a new peer node in the channel. On giving, channel genesis block, it kept trying to fetch next blocks (starting from 1) by reaching out to orderer defined in the block 0 of the channel.
As expected, the new peer could not fetch any block after block 0! Because all the orderers defined in the channel at the time of its creation were swapped over by different orderers over channel lifetime.

What if instead of swapping the nodes, I need to rotate the TLS certificates of the different consenters in the application channel, such that in  channel lifetime, at some point every consenter has a TLS certificate different from the one present in the channel genesis block. This would again stop the newly added peer nodes to join the channel by blocking them to sync any blocks after the block 0 of the application channel!

I tried looking online if this issue was officially addressed by the community. But could not find any proposed solution for this. Is this a bug and taken into consideration for development? Or is this addressed already?





Re: Confusion related to env variable ORDERER_TLS_CA

conanoc
 

You can find the basics of gPRC TLS authentication here: https://blog.gopheracademy.com/advent-2019/go-grps-and-tls/
The article does not cover the usage of multiple CAs, but we could suppose it would handle the intermediate CAs.
I'd like to add that peers do not connect to orderers in general use cases. Client apps connect to orderers to submit transactions. Clients may need to know the ca cert file, but you also can use service discovery instead of setting the ca cert path manually.

-----Original Message-----
From: "Abhijeet Bhowmik"<abhijeet@...>
To: <fabric@...>;
Cc:
Sent: 2020. 5. 15. (금) 15:57 (GMT+09:00)
Subject: [Hyperledger Fabric] Confusion related to env variable ORDERER_TLS_CA
 

Hello wonderful people,
 
I hope all are doing well. As a beginner, I have a confusion that came to me while writing docker-compose files to build my own network. There is an env variable in the orderer section 
'
- ORDERER_GENERAL_TLS_ROOTCAS=[/etc/hyperledger/tls/orderer/ca.crt]
'  
 
So while TLSing via Peer, I have been told to use orderer's /tls/ca.crt. That's where my confusion lies. If anyways we are gonna use orderer's tls/ca.crt, what's the purpose of having value of ORDERER_GENERAL_TLS_ROOTCAS as array. What other values could I mention there. And what will be their significance? Ideally while TLSing between Server-client, Server presents it's certificate (with public key) during the request and the client doesn't have it pre hand. So if we go by that scenario, maybe either the orderer should present it's cert during the request or else there must be a way that we can use peer side artifacts to do the TLS. I see no point in copying orderer's tls/ca.crt to every peer manually.
 
Definitely I could be wrong. I will be more than happy if someone throws some light on this. Looking forward to it.
 
Thanks and Regards 
Abhijeet Bhowmik 


Adding a peer node when no genesis block orderer exist in the channel #fabric-orderer #raft #hyperledger-fabric

chintanr97@...
 

The peer fails to join the channel in the following scenario:

  1. A channel was created by the Orderer Organization (running 3 orderers in RAFT mode).
  2. A peer organization was added (let's say with 3 peers). Chaincodes were installed, instantiated and invoked several times.
  3. Over channel lifetime, the orderer nodes in channel were modified to the extent that no channel genesis block orderers existed in the channel any longer.
  4. A requirement occurred to add a new peer node in the channel. On giving, channel genesis block, it kept trying to fetch next blocks (starting from 1) by reaching out to orderer defined in the block 0 of the channel.

As expected, the new peer could not fetch any block after block 0! Because all the orderers defined in the channel at the time of its creation were swapped over by different orderers over channel lifetime.

What if instead of swapping the nodes, I need to rotate the TLS certificates of the different consenters in the application channel, such that in  channel lifetime, at some point every consenter has a TLS certificate different from the one present in the channel genesis block. This would again stop the newly added peer nodes to join the channel by blocking them to sync any blocks after the block 0 of the application channel!

I tried looking online if this issue was officially addressed by the community. But could not find any proposed solution for this. Is this a bug and taken into consideration for development? Or is this addressed already?


Re: How can I check which hash function is being used to create block hash in hyperledger fabric.

Gari Singh <garis@...>
 

There is a config value for each channel named "HashingAlgorithm".
This is not currently configurable and it set to SHA256.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: fabric@...
From: "qwert limframe"
Sent by: fabric@...
Date: 05/16/2020 07:43AM
Subject: [EXTERNAL] [Hyperledger Fabric] How can I check which hash function is being used to create block hash in hyperledger fabric.

Can you please tell me How I can check which hash function is being used to create block hash in hyperledger fabric while the network is running.


Re: Error: Enrollment information does not exist

Chris Gabriel <alaskadd@...>
 

Hi Cristina,

Posting the resolution here for the benefit of the community:

Resolution to issue fabric-ca-client identity list command is as follows:
1. start the network with the CA option ./network.sh up -ca
2. after the network is up, navigate to (assumes you are already in the test-network directory): cd organizations/peerOrganizations/org1.example.com
3. export cert path using this command: export FABRIC_CA_CLIENT_TLS_CERTFILES=$PWD/ca/ca.org1.example.com-cert.pem
4. export fabric-ca-client home using this command: export FABRIC_CA_CLIENT_HOME=$PWD
5. issue the following command: fabric-ca-client identity list

You should see a list of all the identities registered with the org1 CA.  You can repeat the process by changing the pathing for Org2 and the Orderer Org.


On May 14, 2020, at 1:44 PM, Gmail <alaskadd@...> wrote:

You are not in the client binary directory when issuing the command. You can fix this by exporting the FABRIC_CA_CLIENT_HOME variable and run the command again. This used to get me too, so we updated the CA docs with better instructions.


On May 14, 2020, at 1:35 PM, cridev@... wrote:

Hi all.

I am trying to interact with Fabric through the "fabric-ca-client" binary. I have launched the fabcar, compiled the javascript and node enrollAdmin and node registerUser without errors. However, when I try to launch fabric-ca-client identity list to query the identities that were enrolled and registered by the fabcar (through test-network) this fails and I get a:

ERROR] Enrollment check failed: Idemix enrollment information does not exist
Error: Enrollment information does not exist. Please execute enroll command first. Example:
 fabric-ca-client enroll -u http://user:userpw@serverAddr:serverPort

Note that from the logs I had seen the same exact comment had already went through.

fabric-ca-client enroll -u https://admin:adminpw@localhost:7054 --caname ca-org1 --tls.certfiles /path/to/fabric-ca/org1/tls-cert.pem

Am I missing something obvious here?


How can I check which hash function is being used to create block hash in hyperledger fabric.

qwert limframe
 

Can you please tell me How I can check which hash function is being used to create block hash in hyperledger fabric while the network is running.


Re. Testing, Scalability and Performance - In the context of private data collections usage with a persistant/durable versioned object storage [like couchdb]

Bharg Pvr <pvrbharg@...>
 

Dear team,

Looking for some guidance - has any performance and scalability testing on PDC - in the context of HLF with volumes of 10-20 million records to 100-200 million records. PDC is in play due to regulations, compliance and need to know basis information sharing. The use case also needs long term retention of information. About 10% volume can be a target for queries. We are assuming couchdb or other supported persistent/durable versioned object stores. Please let us know. Thanks


Re: deliverBlocks -> WARN 04d [channel: tracktrace] Rejecting deliver request for [::1]:52044 because of consenter error

Jason Yellick <jyellick@...>
 

"Source address" is a standard TCP/IP networking term.  It is the IP and port to reply to.  You can find many good resources on TCPIP networking, but, in short, it is the address of whoever is on the other side of the networking connection.  You can think of it like the "return address" on an envelope.

In gRPC, the party "on the other end of the line" is called 'the peer', so in this case, since we are reading the orderer server logs, the other party, the peer, is the CLI or SDK.  You see an IPV6 address :::1 (meaning localhost), and an ephemeral port (the sequential high ports you are seeing in the log).  So, my guess would be that you are running the peer CLI from the same location as your orderer process.

~Jason

----- Original message -----
From: Siddharth Jain <siddjain@...>
To: Jason K Yellick <jyellick@...>
Cc: "fabric@..." <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] deliverBlocks -> WARN 04d [channel: tracktrace] Rejecting deliver request for [::1]:52044 because of consenter error
Date: Fri, May 15, 2020 1:50 PM
 
Thanks Jason. Could you explain this a bit? What is a source address? Whose source address?
 
 

From: Jason K Yellick <jyellick@...>
Sent: Friday, May 15, 2020 6:41 AM
To: siddjain@... <siddjain@...>
Cc: fabric@... <fabric@...>
Subject: Re: [Hyperledger Fabric] deliverBlocks -> WARN 04d [channel: tracktrace] Rejecting deliver request for [::1]:52044 because of consenter error
 
The address you are seeing there is the source address and port, not the port the service is listening on.

It's also normal to see those warnings about consenter errors shortly after channel creation because the client may begin polling for the genesis block before the consenters have had a chance to form a quorum.

~Jason
 
----- Original message -----
From: "Siddharth Jain" <siddjain@...>
Sent by: fabric@...
To: "fabric@..." <fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] deliverBlocks -> WARN 04d [channel: tracktrace] Rejecting deliver request for [::1]:52044 because of consenter error
Date: Thu, May 14, 2020 5:16 PM
 
we have a network of Raft orderers. when we tried to created a channel we saw these warnings in the logs
 

2020-05-14 11:38:52.521 PDT [common.deliver] deliverBlocks -> WARN 04d [channel: tracktrace] Rejecting deliver request for [::1]:52044 because of consenter error

2020-05-14 11:38:52.521 PDT [comm.grpc.server] 1 -> INFO 04e streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=[::1]:52044 grpc.code=OK grpc.call_duration=203.915648ms

2020-05-14 11:38:52.727 PDT [common.deliver] deliverBlocks -> WARN 04f [channel: tracktrace] Rejecting deliver request for [::1]:52045 because of consenter error

2020-05-14 11:38:52.727 PDT [comm.grpc.server] 1 -> INFO 050 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=[::1]:52045 grpc.code=OK grpc.call_duration=203.352982ms

2020-05-14 11:38:52.929 PDT [common.deliver] deliverBlocks -> WARN 051 [channel: tracktrace] Rejecting deliver request for [::1]:52046 because of consenter error

2020-05-14 11:38:52.929 PDT [comm.grpc.server] 1 -> INFO 052 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=[::1]:52046 grpc.code=OK grpc.call_duration=200.740112ms

 
the channel still got created. we are not using ports 52044, 52045, 52046 at all. Not sure from where it is getting these ports. anyone knows what this is about?
 
 


Re: deliverBlocks -> WARN 04d [channel: tracktrace] Rejecting deliver request for [::1]:52044 because of consenter error

Siddharth Jain
 

Thanks Jason. Could you explain this a bit? What is a source address? Whose source address?


From: Jason K Yellick <jyellick@...>
Sent: Friday, May 15, 2020 6:41 AM
To: siddjain@... <siddjain@...>
Cc: fabric@... <fabric@...>
Subject: Re: [Hyperledger Fabric] deliverBlocks -> WARN 04d [channel: tracktrace] Rejecting deliver request for [::1]:52044 because of consenter error
 
The address you are seeing there is the source address and port, not the port the service is listening on.

It's also normal to see those warnings about consenter errors shortly after channel creation because the client may begin polling for the genesis block before the consenters have had a chance to form a quorum.

~Jason
 

----- Original message -----
From: "Siddharth Jain" <siddjain@...>
Sent by: fabric@...
To: "fabric@..." <fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] deliverBlocks -> WARN 04d [channel: tracktrace] Rejecting deliver request for [::1]:52044 because of consenter error
Date: Thu, May 14, 2020 5:16 PM
 
we have a network of Raft orderers. when we tried to created a channel we saw these warnings in the logs
 

2020-05-14 11:38:52.521 PDT [common.deliver] deliverBlocks -> WARN 04d [channel: tracktrace] Rejecting deliver request for [::1]:52044 because of consenter error

2020-05-14 11:38:52.521 PDT [comm.grpc.server] 1 -> INFO 04e streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=[::1]:52044 grpc.code=OK grpc.call_duration=203.915648ms

2020-05-14 11:38:52.727 PDT [common.deliver] deliverBlocks -> WARN 04f [channel: tracktrace] Rejecting deliver request for [::1]:52045 because of consenter error

2020-05-14 11:38:52.727 PDT [comm.grpc.server] 1 -> INFO 050 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=[::1]:52045 grpc.code=OK grpc.call_duration=203.352982ms

2020-05-14 11:38:52.929 PDT [common.deliver] deliverBlocks -> WARN 051 [channel: tracktrace] Rejecting deliver request for [::1]:52046 because of consenter error

2020-05-14 11:38:52.929 PDT [comm.grpc.server] 1 -> INFO 052 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=[::1]:52046 grpc.code=OK grpc.call_duration=200.740112ms

 
the channel still got created. we are not using ports 52044, 52045, 52046 at all. Not sure from where it is getting these ports. anyone knows what this is about?
 


Re: Possible configuration of first-come-first-serve ordering policy

Jason Yellick <jyellick@...>
 

Transactions are placed into blocks, by the consensus plugin.  So, for Raft, you'll see this done https://github.com/hyperledger/fabric/blob/9715155109cd7992c0d4d7417b97dfb9d210c4da/orderer/consensus/etcdraft/chain.go#L810-L816

It would of course be nice if we had a property like "all the timestamps on the transactions will be ordered monotonically in the blockchain."  But, Fabric is an asynchronous system, so it's simply not possible.

How long do you wait? If you wait 30 seconds, what if the client's message is delayed by 31 seconds? Then you've broken the premise.  You cannot wait forever.  So, in general, any re-ordering you do of client transactions will have failure cases under asynchrony.
 
With a more invasive approach to the consensus protocol, like assigning client sequence numbers to all requests, it might be possible to achieve some weaker guarantees like "client tx with sequence number n will not commit until after client tx with sequence number n-1", but this would not be a trivial exercise and would require additional consensus than simple total order. All this to say, a particular consensus implementation might be able to offer stronger guarantees, with cooperation from the client, but there's no way to do this reliably in Fabric as it stands today.

Thanks,
~Jason


----- Original message -----
From: "Nikos Kapsoulis" <nkapsoulis@...>
Sent by: fabric@...
To: Gari Singh <garis@...>
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Possible configuration of first-come-first-serve ordering policy
Date: Fri, May 15, 2020 9:43 AM
 

Gari, thank you for your answer. I am answering inline.

What are you trying / hoping to do?
Modify the following - keep reading please.
There is no "policy" per se and strictly speaking there is no guarantee that the transactions will be ordered in the exact order in which they were sent.

Agreed.

However, I think that after the transactions are sent to the orderer and the orderer puts them in a strict order, then the peers will use the same order when validating and committing transactions. Thus, I suppose that somewhere in the orderer's code exists the point or function where the orderer sends the transactions to the peers, and hopefully it could be somewhat configured or modified. (For instance, in a way of sorting them by Header or something else.).

That being said, it is currently generally this case that transactions are ordered in the order received as they are processed from a gRPC stream which does queue messages in the order in which they are received.

Again, correct me if I am wrong, I am trying to locate this exact point in code where the transactions are received, ordered and then sent to the peers (1 of the 3 points will do I guess), and hopefully configure a custom orderer. Thank you in advance.

With kind regards,

-Nikos

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: fabric@...
From: "Nikos Kapsoulis"
Sent by: fabric@...
Date: 05/15/2020 08:44AM
Subject: [EXTERNAL] [Hyperledger Fabric] Possible configuration of first-come-first-serve ordering policy

                   Hi,
     according to orderer documentation, in phase         two the "the ordering service puts the transactions into           a strict order". Where in the orderer's         code (or anywhere else) is it possible to configure this "first-come-first-serve"       policy? Thank you in advance.
     With kind regards,
    
     -Nikos
    
    
    
    







 
 


Re: #couchdb #fabric-chaincode #fabric-sdk-java #couchdb #fabric-chaincode #fabric-sdk-java

Matthew White
 

Just for confirmation - spoke with Marek on rocketchat, and the fix for FABCJ-285 will resolve this... will look to put our a patch release in the coming week. 
 
 
Regards, Matthew.
Matthew B White  IBM Blockchain Solutions Architect
 
Email me at WHITEMAT@...
Find me on StackOverflow, and generally at  calanais.me.uk
 
Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday 
IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN

"The wrong answers are the ones you go looking for when the right answers stare you in the face"
 
 
 
----- Original message -----
From: Marek Malik <info@...>
To: Matthew White <WHITEMAT@...>
Cc: "fabric@..." <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #couchdb #fabric-chaincode #fabric-sdk-java
Date: Fri, May 15, 2020 1:38 PM
 

Hi Matthew,

 

Thank you!

I think I’m still not using that fix, the problem with the time is constant since I remember, it’s just depended on what the data volume is. The weirds thing is that FabCar is running smooth.
I didn’t tested uploading the data from outside the chaincode rather than on `initLedger`. If you need anything I’m on rocketchat @c0deh0use.

 



Marek Malik

 

Od: Matthew White <WHITEMAT@...>
Data: piątek, 15 maja 2020 14:31
Do: Marek Malik <info@...>
DW: "fabric@..." <fabric@...>
Temat: RE: [Hyperledger Fabric] #couchdb #fabric-chaincode #fabric-sdk-java

 

Hello; let me have a look at your repo... just to double check it couldn't be the perf issue fixes this week?

 

 

Regards, Matthew.


Matthew B White  IBM Blockchain Solutions Architect

 

Email me at WHITEMAT@...

Find me on StackOverflow, and generally at  calanais.me.uk

 

Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday 

IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN


"The wrong answers are the ones you go looking for when the right answers stare you in the face"
 

 

 

----- Original message -----
From: "Marek Malik" <info@...>
Sent by: fabric@...
To: Senthilnathan N <cendhu@...>
Cc: "fabric@..." <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #couchdb #fabric-chaincode #fabric-sdk-java
Date: Fri, May 15, 2020 1:23 PM
 

Hello guys,

Sorry for being such a pain in the ass, but could one please help with that darn performance issue ?
I have tried to strip down my chaincode and do a copy-past of what the FabCar java chaincode has and do my chaincode on its based (both the setup and the chaincode build).

Not much have this helped, and I’m running out of points where my chaincode can differ from the sample fabcar.
I’m only interested in the getQueryResult
rich query feature in CouchDB.


Bellow you can access my repo with the two chaincodes setup and client apps to test the responses.
https://github.com/Marek00Malik/fabric-samples/tree/chaincode-performance-test


Besides the FabCar java chaincode there is a poc-services chaincode, and also a poc-services client app.
You can start the network and deploy both chaincodes by running 
` ./startFabric.sh fabcar` from the poc-services folder.
The chaincode is located in the chaincodes/poc-services folder as the fabcar one is.

The results differ by around 30 seconds.
FabCar                        - 3.5 seconds
My chaincode             - 31 seconds.


Can someone review and help me with this one, I don’t have any other ideas where the additional time difference could be sitting.


Best Regards,
Marek Malik

 

Od: <fabric@...> w imieniu użytkownika Marek Malik <info@...>
Data: piątek, 1 maja 2020 22:17
Do: Senthilnathan N <cendhu@...>
DW: "fabric@..." <fabric@...>
Temat: Re: [Hyperledger Fabric] #couchdb #fabric-chaincode #fabric-sdk-java

 

I didn’t tested placing the content in the root of the project, as usually the META-INF is placed in the app resource directory (as stated in the initial email).

Remarkably, this actually worked!
I assume that the process of setting up the couch db and any configuration/ doesn’t necessary have anything to do with the actual chain code deployment, it’s just packaged in the root with the code ?




Anyway, Thanks for your suggestion 😊

Best Regards,
Marek

Od: Senthilnathan N <cendhu@...>
Data: piątek, 1 maja 2020 19:32
Do: Marek Malik <info@...>
DW: "fabric@..." <fabric@...>
Temat: Re: [Hyperledger Fabric] #couchdb #fabric-chaincode #fabric-sdk-java

 

Regards,

Senthil

 

 

On Fri, May 1, 2020 at 10:44 PM <info@...> wrote:

I'm trying to create a CouchDB index while deploying the Java-based chain code.
I was following the documentation from there:
https://hyperledger-fabric.readthedocs.io/en/release-2.0/couchdb_tutorial.html#verify-index-was-deployed

I'm not able to get the index to be created while deploying the chaincode on the peer. I cannot see any log entry like "[couchdb] CreateIndex ->" when checking peer logs.

I’m trying to create a simple index, it’s stored in the following path: `root-dir/src/main/resources/META-INF/statedb/couchdb/indexes`
with the filename `pocServicesIdx.json` and content:

```
{

  "index": {

    "fields": [

      "projectId",

      "data_type"

    ]

  },

  "ddoc": "pocServicesDoc",

  "name": "pocServicesIdx",

  "type": "json"

}


```



I’m able to create an index manually doing it from the Fauxton admin console so the syntax should be valid.
The problem is that I’m not even getting any error logs related to creating indexes when deploying the chaincode when running the peer with flag FABRIC_LOGGING_SPEC

Using Fabric 2.0.0 version. 

Can anybody help or give some suggestions?

 

 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 05/15/2020 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When:
Friday, 15 May 2020
4:00pm to 5:00pm
(GMT+01:00) Europe/London

Where:
https://zoom.us/j/6223336701

Organizer:
a_o-dowd@... +441962816761

Description:
Documentation workgroup call.
Agenda, minutes and recordings :https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group


Upcoming Event: Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 05/15/2020 4:00pm-5:00pm #cal-reminder

fabric@lists.hyperledger.org Calendar <fabric@...>
 

Reminder: Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When: Friday, 15 May 2020, 4:00pm to 5:00pm, (GMT+01:00) Europe/London

Where:https://zoom.us/j/6223336701

View Event

Organizer: Anthony O'Dowd a_o-dowd@... +441962816761

Description: Documentation workgroup call.
Agenda, minutes and recordings :https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group


Re: Possible configuration of first-come-first-serve ordering policy

Nikos Kapsoulis
 

Gari, thank you for your answer. I am answering inline.

What are you trying / hoping to do?
Modify the following - keep reading please.
There is no "policy" per se and strictly speaking there is no guarantee that the transactions will be ordered in the exact order in which they were sent.

Agreed.

However, I think that after the transactions are sent to the orderer and the orderer puts them in a strict order, then the peers will use the same order when validating and committing transactions. Thus, I suppose that somewhere in the orderer's code exists the point or function where the orderer sends the transactions to the peers, and hopefully it could be somewhat configured or modified. (For instance, in a way of sorting them by Header or something else.).

That being said, it is currently generally this case that transactions are ordered in the order received as they are processed from a gRPC stream which does queue messages in the order in which they are received.

Again, correct me if I am wrong, I am trying to locate this exact point in code where the transactions are received, ordered and then sent to the peers (1 of the 3 points will do I guess), and hopefully configure a custom orderer. Thank you in advance.

With kind regards,

-Nikos

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: fabric@...
From: "Nikos Kapsoulis" 
Sent by: fabric@...
Date: 05/15/2020 08:44AM
Subject: [EXTERNAL] [Hyperledger Fabric] Possible configuration of first-come-first-serve ordering policy

                   Hi,
     according to orderer documentation, in phase         two the "the ordering service puts the transactions into           a strict order". Where in the orderer's         code (or anywhere else) is it possible to configure this "first-come-first-serve"       policy? Thank you in advance.
     With kind regards,
     
     -Nikos
     
     
     
     








Re: deliverBlocks -> WARN 04d [channel: tracktrace] Rejecting deliver request for [::1]:52044 because of consenter error

Jason Yellick <jyellick@...>
 

The address you are seeing there is the source address and port, not the port the service is listening on.

It's also normal to see those warnings about consenter errors shortly after channel creation because the client may begin polling for the genesis block before the consenters have had a chance to form a quorum.

~Jason
 

----- Original message -----
From: "Siddharth Jain" <siddjain@...>
Sent by: fabric@...
To: "fabric@..." <fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] deliverBlocks -> WARN 04d [channel: tracktrace] Rejecting deliver request for [::1]:52044 because of consenter error
Date: Thu, May 14, 2020 5:16 PM
 
we have a network of Raft orderers. when we tried to created a channel we saw these warnings in the logs
 

2020-05-14 11:38:52.521 PDT [common.deliver] deliverBlocks -> WARN 04d [channel: tracktrace] Rejecting deliver request for [::1]:52044 because of consenter error

2020-05-14 11:38:52.521 PDT [comm.grpc.server] 1 -> INFO 04e streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=[::1]:52044 grpc.code=OK grpc.call_duration=203.915648ms

2020-05-14 11:38:52.727 PDT [common.deliver] deliverBlocks -> WARN 04f [channel: tracktrace] Rejecting deliver request for [::1]:52045 because of consenter error

2020-05-14 11:38:52.727 PDT [comm.grpc.server] 1 -> INFO 050 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=[::1]:52045 grpc.code=OK grpc.call_duration=203.352982ms

2020-05-14 11:38:52.929 PDT [common.deliver] deliverBlocks -> WARN 051 [channel: tracktrace] Rejecting deliver request for [::1]:52046 because of consenter error

2020-05-14 11:38:52.929 PDT [comm.grpc.server] 1 -> INFO 052 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=[::1]:52046 grpc.code=OK grpc.call_duration=200.740112ms

 
the channel still got created. we are not using ports 52044, 52045, 52046 at all. Not sure from where it is getting these ports. anyone knows what this is about?
 


Re: Possible configuration of first-come-first-serve ordering policy

Gari Singh <garis@...>
 

What are you trying / hoping to do?

There is no "policy" per se and strictly speaking there is no guarantee that the transactions will be ordered in the exact order in which they were sent.
That being said, it is currently generally this case that transactions are ordered in the order received as they are processed from a gRPC stream which does queue messages in the order in which they are received.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: fabric@...
From: "Nikos Kapsoulis"
Sent by: fabric@...
Date: 05/15/2020 08:44AM
Subject: [EXTERNAL] [Hyperledger Fabric] Possible configuration of first-come-first-serve ordering policy

Hi,
according to orderer documentation, in phase two the "the ordering service puts the transactions into a strict order". Where in the orderer's code (or anywhere else) is it possible to configure this "first-come-first-serve" policy? Thank you in advance.
With kind regards,

-Nikos

3221 - 3240 of 11518