Date   

Re: Unable to Query data from Hyperledger Fabric #couchdb #fabric-chaincode #hyperledger-fabric

cesare.valitutto@...
 

I had a similar error and ended up being an issue with the high number of records (400k+) processed by the query. I am not sure whether this could be related to your case, but using indexes (and even better with partial_filter_selector) solved it for me.


Documentation Workgroup: Agenda for Friday, 15 Jan

Pam Andrejko
 

We will resume the documentation workgroup Western hemisphere calls as usual this Friday.  Please attend, you are very welcome!

You can read about our last call at https://wiki.hyperledger.org/display/fabric/2020+12+11+DWG+Agenda which includes  the minutes and a recording is available: https://wiki.hyperledger.org/display/fabric/Recordings
Thank you to all of our workgroup members for your contributions and collaboration in 2020. 

Our Western hemisphere call will be covering 
  • Release progress
  • Guest appearance by Andrew Coleman who will provide an update on the Fabric Gateway
  • Update on the Fabric translation campaign from David
  • Updates to the Network key concept topic by Joe
  • Updates to the test network sample
  • Updates to the Getting Started by Rob


See https://wiki.hyperledger.org/display/fabric/2021+01+15+DWG+Agenda for this week's agenda and feel free to add any topics you want to discuss. 

You are welcome to contribute using the wiki, including helping to build next week's agenda: https://wiki.hyperledger.org/display/fabric/2021+01+22+DWG+Agenda

Thanks!

Meeting Details
-------------
Please use the following link to attend the meeting:


Join Zoom Meeting

https://zoom.us/j/6223336701?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09

 

Meeting ID: 622 333 6701

Passcode: 475869




Hyperledger Project Quarterly Update Due #tsc-project-update - Thu, 01/21/2021 #tsc-project-update #cal-reminder

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

Reminder: Hyperledger Project Quarterly Update Due #tsc-project-update

When: Thursday, 21 January 2021

View Event

Organizer: community-architects@...

Description: Please file a project status report for the TSC here:

https://wiki.hyperledger.org/display/TSC/2021+Project+Updates

https://wiki.hyperledger.org/display/TSC/2021+TSC+Project+Update+Calendar


Power of Administrator organiization in channel #hyperledger-fabric #channel #consortium #administrator-organiization

vishnurai1999@...
 

If a organization is removed from consortium by the administrator organiization will it be removed from channel?


Re: Fabric for Covid-19 Immunity Passports on Fabric deployed on multi-cloud (aws, azure, gcp)

Brian Behlendorf <bbehlendorf@...>
 

Hi all,

There is quite a bit of activity going on now re "immunity passports", or better stated "vaccination records" like the digital yellow card you've long used to be able to get certain visas, enter certain countries, or even enroll kids in schools, etc. There are many people now building on top of the standards Hyperledger projects like Indy and Aries long championed - DIDs, Verifiable Credentials, etc. There are some hard and some still unresolved questions about how to do this at the scale of billions of users, the degree of privacy protection desired (which differs country by country), and the ability to revoke credentials (in case, worse of all possible worlds/cases, a batch of vaccines was spoiled before people noticed, etc). There's a community that's been working on these issues since April called the Covid Creds Initiative, who as of last month are now part of the Linux Foundation Public Health project. LFPH is now looking for code bases that implement wallets to hold credentials, or other software that could be used to issue or verify credentials, in a vaccination or test result or other public health context. My hope is we find a way to make these systems interoperable, so that one doesn't need multiple credentials for different contexts - your vax receipt from the clinic in California should allow you to attend a concert in Arizona, or board a plane to the UK and attend a concert there. That use case presumes interop at a couple of different layers, up to how the health authorities in different regions coordinate to trust each others' issued creds. IMHO that should build on top of the TrustOverIP model, which allows for different kinds of underlying "utility network" layers to be used, so hopefully we can get interop even when talking about different networks like the below and different vendors.

Back to Nathan's question, in addition to the one below I've heard of a couple that use Fabric as an underlying ledger for PKI, such as IBM's Health Pass. 

Brian


On 1/10/21 3:54 PM, Mark Rakhmilevich wrote:

Nathan,

   There are some solutions out there along these lines, including our partner Vottun’s PROOF OF HEALTH CREDENTIALS built on Fabric and available on Oracle Blockchain Platform, but could also be deployed on a multi-vendor/multi-cloud network of Fabric nodes.  There are other efforts focused on sharing testing & vaccination status gaining attention: e.g., Common Trust Network sponsored by WEF, but it doesn’t appear to leverage blockchain technology.

 

Mark

 

From: Nathan Aw <Nathan.mk.aw@...>
Sent: Sunday, January 10, 2021 12:54 AM
To: fabric@...
Subject: [Hyperledger Fabric] Fabric for Covid-19 Immunity Passports on Fabric deployed on multi-cloud (aws, azure, gcp)

 

Hi everyone,

 

Has anyone explored the use of fabric for covid-19 immunity passports purposes?

 

These peer nodes could be setup and managed by the various governments, the WHO, etc.

 

Once vaccinated, your details will be inputted into ledger. You could then be issued with a qr code. At the border, upon departure, you could present the qr code to customs. The qr code will then be verified against your passport details etc.

 

To ensure that the solution can be truly, truly resilient, the setup should be deployed on multi-cloud in all regions of the world and zones possible.

 

However, assuming the above can be achieved technically, the most pertinent question remains unanswered: how (1) scalable and (2) secure will this be? 

 

Given that all cross border travellers in the world will need be verified -- can fabric meet such rigorous and stringent requirements?

 

Anyone, any thoughts?

 

Thank you.

 

Regards,

 

Nathan Aw 


-- 
Brian Behlendorf
Managing Director for Blockchain, Healthcare and Identity
bbehlendorf@...
Twitter: @brianbehlendorf


Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 01/15/2021 11:00am-12:00pm #cal-reminder

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

Reminder: Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When: Friday, 15 January 2021, 11:00am to 12:00pm, (GMT-05:00) America/New York

Where:https://zoom.us/my/hyperledger.community.backup?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09

View Event

Organizer: Pam Andrejko pama@...

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

Join Zoom Meeting
https://zoom.us/j/6223336701?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09
 
Meeting ID: 622 333 6701
Passcode: 475869


Re: #fabric-ca #fabric-orderer #hyperledger-fabric Unable to start the Orderer, keep getting "initializing channelconfig failed: could not create channel Consortiums sub-group config:" #fabric-ca #fabric-orderer #hyperledger-fabric

Marek Malik <info@...>
 

Is there any change someone could help here?
I really straggling on finding what is the bottom reason.
The
config.yaml file is read correctly, because if I change the paths or the cert names then I’m getting different errors on the startup.

I’m trying to figure out any differences in the test-network setup and determine if I’m missing anything, or I’m enrolling the orderer identity differently, but I don’t see any differences or I don’t know where to search for.

I starting to look into the orderer codebase, but maybe someone could point into some place as I’m not a go developer.

 

Best Regards,

Marek Malik

 

Od: <fabric@...> w imieniu użytkownika Marek Malik <info@...>
Data: wtorek, 12 stycznia 2021 11:25
Do: Yacov Manevich <YACOVM@...>
DW: "fabric@..." <fabric@...>
Temat: Re: [Hyperledger Fabric] #fabric-ca #fabric-orderer #hyperledger-fabric Unable to start the Orderer, keep getting "initializing channelconfig failed: could not create channel Consortiums sub-group config:"

 

Anyone could help with this one?

I was thinking I have something wrong with the volume what I’m connecting to the container in k8s, but it looks correct.

 

This is the files structure in the container:


/var/hyperledger
/var/hyperledger/channel-artifacts
/var/hyperledger/channel-artifacts/genesis.block
/var/hyperledger/production
/var/hyperledger/production/orderer
/var/hyperledger/production/orderer/index
/var/hyperledger/production/orderer/index/MANIFEST-000000
/var/hyperledger/production/orderer/index/CURRENT
/var/hyperledger/production/orderer/index/000001.log
/var/hyperledger/production/orderer/index/LOG
/var/hyperledger/production/orderer/index/LOCK
/var/hyperledger/production/orderer/chains
/var/hyperledger/orderer
/var/hyperledger/orderer/msp
/var/hyperledger/orderer/msp/signcerts
/var/hyperledger/orderer/msp/signcerts/cert.pem
/var/hyperledger/orderer/msp/config.yaml
/var/hyperledger/orderer/msp/keystore
/var/hyperledger/orderer/msp/keystore/34830a9ce7333287709c65a71ccbeda86998cfd7f57e68b29360247015ebba02_sk
/var/hyperledger/orderer/msp/IssuerPublicKey
/var/hyperledger/orderer/msp/tlscacerts
/var/hyperledger/orderer/msp/tlscacerts/hlf-ca--amvoxdlt-7054.pem
/var/hyperledger/orderer/msp/user
/var/hyperledger/orderer/msp/IssuerRevocationPublicKey
/var/hyperledger/orderer/msp/cacerts
/var/hyperledger/orderer/msp/cacerts/hlf-ca--amvoxdlt-7054.pem
/var/hyperledger/orderer/tls
/var/hyperledger/orderer/tls/server.crt
/var/hyperledger/orderer/tls/signcerts
/var/hyperledger/orderer/tls/signcerts/cert.pem
/var/hyperledger/orderer/tls/keystore
/var/hyperledger/orderer/tls/keystore/b66d2e77cd826f965ea18d4d14d4d3815fa9fd1635469558f05b10e64a466ed7_sk
/var/hyperledger/orderer/tls/IssuerPublicKey
/var/hyperledger/orderer/tls/server.key
/var/hyperledger/orderer/tls/tlscacerts
/var/hyperledger/orderer/tls/tlscacerts/tls-hlf-ca--amvoxdlt-7054.pem
/var/hyperledger/orderer/tls/user
/var/hyperledger/orderer/tls/IssuerRevocationPublicKey
/var/hyperledger/orderer/tls/cacerts
/var/hyperledger/orderer/orderer0.amvox-dlt.io.finished

 

Here is the config.yaml


NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
    OrganizationalUnitIdentifier: client
  PeerOUIdentifier:
    Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
    OrganizationalUnitIdentifier: peer
  AdminOUIdentifier:
    Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
    OrganizationalUnitIdentifier: admin
  OrdererOUIdentifier:
    Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
    OrganizationalUnitIdentifier: orderer

 

In the attachment you will find the debug logging when starting the orderer.

 

I will be greatfull for any help, I’m not sure where is the problem, and all files seem to be located in the correct folders.

 

Best Regards,

Marek Malik

 

Od: <fabric@...> w imieniu użytkownika Marek Malik <info@...>
Data: piątek, 8 stycznia 2021 23:55
Do: Yacov Manevich <YACOVM@...>
DW: "fabric@..." <fabric@...>
Temat: Re: [Hyperledger Fabric] #fabric-ca #fabric-orderer #hyperledger-fabric Unable to start the Orderer, keep getting "initializing channelconfig failed: could not create channel Consortiums sub-group config:"

 

Thanks Yacov, but I don’t intend to create the admincerts folder.

“define the admin OU in the config.yaml of the MSP folder”
This is exactly what I’m doing -> This is the config.yaml from the mail:

NodeOUs:
   Enable: true
   ClientOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: client
   PeerOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: peer
   AdminOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: admin
   OrdererOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: orderer





The cert is stored in the cacerts folder in the MSP dir.
Anything else that I’m missing ?

 

 

Best Regards,

Marek Malik

 

Od: Yacov Manevich <YACOVM@...>
Data: piątek, 8 stycznia 2021 22:58
Do: Marek Malik <info@...>
DW: "fabric@..." <fabric@...>
Temat: Re: [Hyperledger Fabric] #fabric-ca #fabric-orderer #hyperledger-fabric Unable to start the Orderer, keep getting "initializing channelconfig failed: could not create channel Consortiums sub-group config:"

 

Put admin certificates in the admin folder, or define the admin OU in the config.yaml of the MSP folder



From:        "Marek Malik" <info@...>
To:        fabric@...
Date:        01/08/2021 11:49 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] #fabric-ca #fabric-orderer #hyperledger-fabric Unable to start the Orderer, keep getting "initializing channelconfig failed: could not create channel Consortiums sub-group config:"
Sent by:        fabric@...





Hello Guys, 

I'm trying to setup my network to work in Kubernetes cluster, but my Orderer keeps failing. I'm getting the following error: 
Main -> PANI 005 Failed validating bootstrap block: initializing channelconfig failed: could not create channel Consortiums sub-group config: setting up the MSP manager failed: administrators must be declared when no admin ou classification is set
panic: Failed validating bootstrap block: initializing channelconfig failed: could not create channel Consortiums sub-group config: setting up the MSP manager failed: administrators must be declared when no admin ou classification is set

Could anyone help?


I'm following a similar setup as the test-network from the samples: I have the Fabric-CA generating the certificates & using the NodeOUs (it is enabled in crypto-config.yaml): 

This is the configtx.yaml that I'm using to generate the genesis.block. It is also located in the msp folder when running the Orderer.

NodeOUs:
   Enable: true
   ClientOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: client
   PeerOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: peer
   AdminOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: admin
   OrdererOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: orderer

Orderer: &OrdererDefaults

 # Orderer Type: The orderer implementation to start
 OrdererType: etcdraft

 Addresses:
   - orderer0.amvox-dlt.io:7050

 # Batch Timeout: The amount of time to wait before creating a batch
 BatchTimeout: 3s

 # Batch Size: Controls the number of messages batched into a block
 BatchSize:

   # Max Message Count: The maximum number of messages to permit in a batch
   MaxMessageCount: 500

   # Absolute Max Bytes: The absolute maximum number of bytes allowed for
   # the serialized messages in a batch.
   AbsoluteMaxBytes: 99 MB

   # Preferred Max Bytes: The preferred maximum number of bytes allowed for
   # the serialized messages in a batch. A message larger than the preferred
   # max bytes will result in a batch larger than preferred max bytes.
   PreferredMaxBytes: 512 KB

 EtcdRaft:
   Consenters:
     - Host: orderer0.amvox-dlt.io
       Port: 7050
       ClientTLSCert: /hlf_config/crypto-config/ordererOrganizations/amvox-dlt.io/orderers/orderer0.amvox-dlt.io/tls/server.crt
       ServerTLSCert: /hlf_config/crypto-config/ordererOrganizations/amvox-dlt.io/orderers/orderer0.amvox-dlt.io/tls/server.crt


 # Organizations is the list of orgs which are defined as participants on
 # the orderer side of the network
 Organizations:

 # Policies defines the set of policies at this level of the config tree
 # For Orderer policies, their canonical path is
 #   /Channel/Orderer/<PolicyName>
 Policies:
   Readers:
     Type: ImplicitMeta
     Rule: "ANY Readers"
   Writers:
     Type: ImplicitMeta
     Rule: "ANY Writers"
   Admins:
     Type: ImplicitMeta
     Rule: "MAJORITY Admins"
   # BlockValidation specifies what signatures must be included in the block
   # from the orderer for the peer to validate it.
   BlockValidation:
     Type: ImplicitMeta
     Rule: "ANY Writers"

 # Capabilities describes the orderer level capabilities, see the
 # dedicated Capabilities section elsewhere in this file for a full
 # description
 Capabilities:
   <<: *OrdererCapabilities

################################################################################
#
#   CHANNEL
#
#   This section defines the values to encode into a config transaction or
#   genesis block for channel related parameters.
#
################################################################################
Channel: &ChannelDefaults
 # Policies defines the set of policies at this level of the config tree
 # For Channel policies, their canonical path is
 #   /Channel/<PolicyName>
 Policies:
   # Who may invoke the 'Deliver' API
   Readers:
     Type: ImplicitMeta
     Rule: "ANY Readers"
   # Who may invoke the 'Broadcast' API
   Writers:
     Type: ImplicitMeta
     Rule: "ANY Writers"
   # By default, who may modify elements at this config level
   Admins:
     Type: ImplicitMeta
     Rule: "MAJORITY Admins"

 # Capabilities describes the channel level capabilities, see the
 # dedicated Capabilities section elsewhere in this file for a full
 # description
 Capabilities:
   <<: *ChannelCapabilities

################################################################################
#
#   Profile
#
#   - Different configuration profiles may be encoded here to be specified
#   as parameters to the configtxgen tool
#
################################################################################
Profiles:

 amvox-channel:
   Consortium: AmvoxConsortium
   <<: *ChannelDefaults
   Application:
     <<: *ApplicationDefaults
     Organizations:
       - *Amvox
       - *Org2
       - *Org3
     Capabilities:
       <<: *ApplicationCapabilities

 OrdererGenesis:
   <<: *ChannelDefaults
   Orderer:
     <<: *OrdererDefaults
     OrdererType: etcdraft
     EtcdRaft:
       Consenters:
         - Host: orderer0.amvox-dlt.io
           Port: 7050
           ClientTLSCert: /hlf_config/crypto-config/ordererOrganizations/amvox-dlt.io/orderers/orderer0.amvox-dlt.io/tls/server.crt
           ServerTLSCert: /hlf_config/crypto-config/ordererOrganizations/amvox-dlt.io/orderers/orderer0.amvox-dlt.io/tls/server.crt
     Addresses:
       - orderer0.amvox-dlt.io:7050

     Organizations:
       - *AmvoxDLT
     Capabilities:
       <<: *OrdererCapabilities

   Application:
     <<: *ApplicationDefaults
     Organizations:
       - <<: *AmvoxDLT

   Consortiums:
     AmvoxConsortium:
       Organizations:
         - *Amvox
         - *Org2
         - *Org3

Anyone has any ideas why ordered can not get started?

 






Re: Peer logs filled with TLS handshake error #fabric #tls #ssl #fabric-questions

Matthew Sykes
 

EOF - End of File. It's likely indicating the other end of the connection has closed during the handshake, that a network error occurred, or that a record header with an incorrect length was received.
i/o timeout - the error string included in expired deadline errors. These are generally read timeouts.

The addresses in the errors are telling you the addresses of clients that are closing their connections or failing to send data within a reasonable time. For gRPC, the connection timeout is used as the deadline and covers the TLS handshake and HTTP/2 protocol negotiation. This can be changed for the peer by setting the `peer.connectionTimeout` config key. The default appears to be 5s.

You need to investigate the root cause in your own environment and make appropriate changes.


JWT Authentication #rfc

Matthew Sykes
 

I have created a proposal for JWT based authentication that can be used with the channel participation API. The goal is enable the use of MSP identities on the API and remove the requirement for mutual TLS.

For those that are interested in this work, please take a look at https://github.com/hyperledger/fabric-rfcs/pull/41.

Thanks.


Peer logs filled with TLS handshake error #fabric #tls #ssl #fabric-questions

chintanr97@...
 

Hi Team, in peer logs we keep seeing following error messages:
```
2021-01-12 14:36:08.217 UTC [core.comm] ServerHandshake -> ERRO 2278 TLS handshake failed with error read tcp <ip1>:7052-><ip3>:60870: i/o timeout server=ChaincodeServer remoteaddress=<ip3>:60870
2021-01-12 14:36:08.218 UTC [core.comm] ServerHandshake -> ERRO 2279 TLS handshake failed with error read tcp <ip1>:7051-><ip3>:60872: i/o timeout server=PeerServer remoteaddress=<ip3>:60872
2021-01-12 14:36:08.573 UTC [core.comm] ServerHandshake -> ERRO 227a TLS handshake failed with error read tcp <ip1>:7052-><ip4>:54263: i/o timeout server=ChaincodeServer remoteaddress=<ip4>:54263
2021-01-12 14:36:08.575 UTC [core.comm] ServerHandshake -> ERRO 227b TLS handshake failed with error read tcp <ip1>:7051-><ip4>:54262: i/o timeout server=PeerServer remoteaddress=<ip4>:54262
2021-01-12 14:36:12.287 UTC [core.comm] ServerHandshake -> ERRO 227c TLS handshake failed with error EOF server=PeerServer remoteaddress=<ip2>:65264
2021-01-12 14:36:12.601 UTC [core.comm] ServerHandshake -> ERRO 227d TLS handshake failed with error read tcp <ip1>:7052-><ip2>:65265: i/o timeout server=ChaincodeServer remoteaddress=<ip2>:65265
2021-01-12 14:36:13.231 UTC [core.comm] ServerHandshake -> ERRO 227e TLS handshake failed with error EOF server=PeerServer remoteaddress=<ip3>:60887
2021-01-12 14:36:13.233 UTC [core.comm] ServerHandshake -> ERRO 227f TLS handshake failed with error EOF server=ChaincodeServer remoteaddress=<ip3>:60888
```

On our end, we verified the TLS certificates and they seem to be correctly configured with required SANs. I wanted to understand the implication of the "i/o timeout" error and "error EOF" messages.


Re: Unable to Query data from Hyperledger Fabric #couchdb #fabric-chaincode #hyperledger-fabric

chintanr97@...
 

Hi David, That's correct! However, we found a minor fix in the chaincode and post that the latest error logs give following stack trace:

```

[34m2021-01-12 09:22:03.362 UTC [endorser] callChaincode -> INFO 10f7b [][] Entry chaincode: name:"<ccName>" 

[31m2021-01-12 09:22:41.290 UTC [chaincode] BuildQueryResponse -> ERRO [0m Failed to get query result from iterator

[31m2021-01-12 09:22:41.290 UTC [chaincode] HandleTransaction -> ERRO [0m [] Failed to handle QUERY_STATE_NEXT. error: net/http: request canceled (Client.Timeout exceeded while reading body)

error reading response body

github.com/hyperledger/fabric/core/ledger/util/couchdb.(*CouchDatabase).QueryDocuments

/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:1072

github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb.(*queryScanner).executeQueryWithBookmark

/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go:483

github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb.(*queryScanner).Next

/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go:731

github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/txmgr/lockbasedtxmgr.(*queryResultsItr).Next

/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/txmgr/lockbasedtxmgr/helper.go:433

github.com/hyperledger/fabric/core/chaincode.(*QueryResponseGenerator).BuildQueryResponse

/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/query_response_generator.go:32

github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleQueryStateNext

/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:824

github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleTransaction

/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:276

runtime.goexit

/opt/go/src/runtime/asm_amd64.s:1337

github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleQueryStateNext

/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:827

github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleTransaction

/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:276

runtime.goexit

/opt/go/src/runtime/asm_amd64.s:1337

QUERY_STATE_NEXT failed: transaction ID: <tid>

github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleTransaction

/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:280

runtime.goexit

/opt/go/src/runtime/asm_amd64.s:1337

[34m2021-01-12 09:22:41.291 UTC [<cc>] func2 -> INFO [0m 2021/01/12 09:22:41 error getting results for query response 

[34m2021-01-12 09:22:41.291 UTC [<cc>] func2 -> INFO [0m error: QUERY_STATE_NEXT failed: transaction ID: <tid>: error reading response body: net/http: request canceled (Client.Timeout exceeded while reading body)

[34m2021-01-12 09:22:41.291 UTC [endorser] callChaincode -> INFO [0m [<channel>][] Exit chaincode: name:"<ccName>"  (37928ms)
[31m2021-01-12 09:22:41.300 UTC [endorser] ProcessProposal -> ERRO [0m [<channel>][] simulateProposal() resulted in chaincode name:"<ccName>"  response status 500 for txid: <tid>
```

In the total 4 iterations of query we did, the timestamp in the second last log line, "Exit chaincode: name: ..." was: 49695ms, 55657ms, 37928ms (above) snippet, and 38826ms.

So, I am not sure now if it is "ledger.state.couchDBConfig.requestTimeout" (which has been set to 35 s), or if it is "CORE_CHAINCODE_EXECUTETIMEOUT" (updated to 300s).


Re: Operations Smart Contract for Hyperledger Fabric v2.x

Sato, Tatsuya
 

Thank you for your email.

Are you going to update the tool accordingly?
Yes, we are going to update this tool.
Support for channel participation without system channel is one of the future features.

Tatsuya Sato

-----Original Message-----
From: fabric@... <fabric@...> On Behalf Of Yueming Xu
Sent: Tuesday, January 12, 2021 8:10 AM
To: fabric@...
Subject: [EXT] Re: [Hyperledger Fabric] Operations Smart Contract for Hyperledger Fabric v2.x

I like your idea of managing chaincode and channels using blockchain. Fabric v2.3 has removed the dependency of system channel and consortium. Are you going to update the tool accordingly?




[-----WARNING-----] This email originated outside of Hitachi. [-----WARNING-----] DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.


Write Fabric chaincode with zero code #fabric #fabric-chaincode

Yueming Xu
 

If you do not like to write boilerplate code repeatedly, or spend time to learn a new programming language supported by the Fabric chaincode.  You may want to check this out: https://github.com/open-dovetail/fabric-chaincode.git.  It is completely open source, and you can develop chaincode without any programming.  You need to know only JSON data format, and everything else is taken care of by the visual programming environment.  Please let me know if you see any issues.  I would also appreciate recommendations for improvement.


Re: Operations Smart Contract for Hyperledger Fabric v2.x

Yueming Xu
 

I like your idea of managing chaincode and channels using blockchain. Fabric v2.3 has removed the dependency of system channel and consortium. Are you going to update the tool accordingly?


Private Chaincode Lab - Tue, 01/12/2021 #cal-notice

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

Private Chaincode Lab

When:
Tuesday, 12 January 2021
8:00am to 9:00am
(GMT-08:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Organizer:
bur@...

Description:
Two of the Hyperleger Labs projects (private data objects and private chain code) are collaborating to develop a "private smart contracts" capability.

Join Zoom Meeting https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09 Meeting ID: 518 494 7650 Passcode: 475869


Re: Unable to Query data from Hyperledger Fabric #couchdb #fabric-chaincode #hyperledger-fabric

David Enyeart
 

Your first log snippet showed CouchDB queries timing out after 35 seconds each. This is the core.yaml ledger.state.couchDBConfig.requestTimeout of 35s. It means that CouchDB is still processing the query when the peer client gives up on it.


Dave Enyeart

chintanr97---01/12/2021 09:31:22 AM---Thanks a lot David for your response. So digging deeper into the logs, we found that peer was return

From: chintanr97@...
To: fabric@...
Date: 01/12/2021 09:31 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Unable to Query data from Hyperledger Fabric #couchdb #fabric-chaincode #hyperledger-fabric
Sent by: fabric@...





Thanks a lot David for your response. So digging deeper into the logs, we found that peer was returning below error:
[chaincode] BuildQueryResponse -> ERRO Failed
to get query result from iterator [chaincode] HandleTransaction -> ERRO Failed to handle QUERY_STATE_NEXT. error: net/http: request canceled (Client.Timeout exceeded while reading body) error reading response body

I wanted to understand the "Client.Timeout" meaning here. I am understanding that the "Client" could be either the peer to Couch DB connection or it could be the Fabric SDK client to peer connection.

IMO, this looks like the peer to Couch DB connection, where the error is getting logged in peer logs within <60s (from the timeout query request comes to the time it errors out), even when CORE_CHAINCODE_EXECUTETIMEOUT is set to 300s. So, this does not look like a timeout issue. Couch DB is returning error much before the set timeout config on the peer. Health of Couch DB and peer containers seem to be good as well.




Re: Unable to Query data from Hyperledger Fabric #couchdb #fabric-chaincode #hyperledger-fabric

chintanr97@...
 

Thanks a lot David for your response. So digging deeper into the logs, we found that peer was returning below error:
[chaincode] BuildQueryResponse -> ERRO Failed to get query result from iterator [chaincode] HandleTransaction -> ERRO Failed to handle QUERY_STATE_NEXT. error: net/http: request canceled (Client.Timeout exceeded while reading body) error reading response body

I wanted to understand the "Client.Timeout" meaning here. I am understanding that the "Client" could be either the peer to Couch DB connection or it could be the Fabric SDK client to peer connection.

IMO, this looks like the peer to Couch DB connection, where the error is getting logged in peer logs within <60s (from the timeout query request comes to the time it errors out), even when CORE_CHAINCODE_EXECUTETIMEOUT is set to 300s. So, this does not look like a timeout issue. Couch DB is returning error much before the set timeout config on the peer. Health of Couch DB and peer containers seem to be good as well. 


Re: Unable to Query data from Hyperledger Fabric #couchdb #fabric-chaincode #hyperledger-fabric

David Enyeart
 

Adding workarounds such as longer timeouts will only prolong your pain. You must address the root cause of the slow query in CouchDB. Troubleshoot it in a separate CouchDB environment until you have figured it out why the query/index are slow in CouchDB.
But honestly, if you expect to get back 20,000 records, you should consider the pattern of querying a downstream data store built from block events. Chaincode is optimized for transactions, not large queries.


Dave Enyeart

chintanr97---01/11/2021 11:50:53 PM---Hi David, The chaincode is performing a select query on the CouchDB documents, and the fields set fo

From: chintanr97@...
To: fabric@...
Date: 01/11/2021 11:50 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Unable to Query data from Hyperledger Fabric #couchdb #fabric-chaincode #hyperledger-fabric
Sent by: fabric@...





Hi David,

The chaincode is performing a select query on the CouchDB documents, and the fields set for filtering the results are indexed while installing and instantiating the chaincode. The single query using the Fabric Node SDK client might be reading around 20K-30K records.

We tried by overriding the peer configuration for following default values with the new values: "CORE_CHAINCODE_EXECUTETIMEOUT=300s" and CORE_PEER_KEEPALIVE_CLIENT_TIMEOUT=300s". We also tried with the SDK connection profile using a property: "grpc.keepalive_timeout_ms": "300000"

So I am not understanding, what we could be missing here. Because the other chaincodes in same channel are able to query the maximum limit of 100K records!




Re: #fabric-ca #fabric-orderer #hyperledger-fabric Unable to start the Orderer, keep getting "initializing channelconfig failed: could not create channel Consortiums sub-group config:" #fabric-ca #fabric-orderer #hyperledger-fabric

Marek Malik <info@...>
 

Anyone could help with this one?

I was thinking I have something wrong with the volume what I’m connecting to the container in k8s, but it looks correct.

 

This is the files structure in the container:

/var/hyperledger
/var/hyperledger/channel-artifacts
/var/hyperledger/channel-artifacts/genesis.block
/var/hyperledger/production
/var/hyperledger/production/orderer
/var/hyperledger/production/orderer/index
/var/hyperledger/production/orderer/index/MANIFEST-000000
/var/hyperledger/production/orderer/index/CURRENT
/var/hyperledger/production/orderer/index/000001.log
/var/hyperledger/production/orderer/index/LOG
/var/hyperledger/production/orderer/index/LOCK
/var/hyperledger/production/orderer/chains
/var/hyperledger/orderer
/var/hyperledger/orderer/msp
/var/hyperledger/orderer/msp/signcerts
/var/hyperledger/orderer/msp/signcerts/cert.pem
/var/hyperledger/orderer/msp/config.yaml
/var/hyperledger/orderer/msp/keystore
/var/hyperledger/orderer/msp/keystore/34830a9ce7333287709c65a71ccbeda86998cfd7f57e68b29360247015ebba02_sk
/var/hyperledger/orderer/msp/IssuerPublicKey
/var/hyperledger/orderer/msp/tlscacerts
/var/hyperledger/orderer/msp/tlscacerts/hlf-ca--amvoxdlt-7054.pem
/var/hyperledger/orderer/msp/user
/var/hyperledger/orderer/msp/IssuerRevocationPublicKey
/var/hyperledger/orderer/msp/cacerts
/var/hyperledger/orderer/msp/cacerts/hlf-ca--amvoxdlt-7054.pem
/var/hyperledger/orderer/tls
/var/hyperledger/orderer/tls/server.crt
/var/hyperledger/orderer/tls/signcerts
/var/hyperledger/orderer/tls/signcerts/cert.pem
/var/hyperledger/orderer/tls/keystore
/var/hyperledger/orderer/tls/keystore/b66d2e77cd826f965ea18d4d14d4d3815fa9fd1635469558f05b10e64a466ed7_sk
/var/hyperledger/orderer/tls/IssuerPublicKey
/var/hyperledger/orderer/tls/server.key
/var/hyperledger/orderer/tls/tlscacerts
/var/hyperledger/orderer/tls/tlscacerts/tls-hlf-ca--amvoxdlt-7054.pem
/var/hyperledger/orderer/tls/user
/var/hyperledger/orderer/tls/IssuerRevocationPublicKey
/var/hyperledger/orderer/tls/cacerts
/var/hyperledger/orderer/orderer0.amvox-dlt.io.finished

 

Here is the config.yaml

NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
    OrganizationalUnitIdentifier: client
  PeerOUIdentifier:
    Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
    OrganizationalUnitIdentifier: peer
  AdminOUIdentifier:
    Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
    OrganizationalUnitIdentifier: admin
  OrdererOUIdentifier:
    Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
    OrganizationalUnitIdentifier: orderer

 

In the attachment you will find the debug logging when starting the orderer.

 

I will be greatfull for any help, I’m not sure where is the problem, and all files seem to be located in the correct folders.

 

Best Regards,

Marek Malik

 

Od: <fabric@...> w imieniu użytkownika Marek Malik <info@...>
Data: piątek, 8 stycznia 2021 23:55
Do: Yacov Manevich <YACOVM@...>
DW: "fabric@..." <fabric@...>
Temat: Re: [Hyperledger Fabric] #fabric-ca #fabric-orderer #hyperledger-fabric Unable to start the Orderer, keep getting "initializing channelconfig failed: could not create channel Consortiums sub-group config:"

 

Thanks Yacov, but I don’t intend to create the admincerts folder.

“define the admin OU in the config.yaml of the MSP folder”
This is exactly what I’m doing -> This is the config.yaml from the mail:

NodeOUs:
   Enable: true
   ClientOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: client
   PeerOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: peer
   AdminOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: admin
   OrdererOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: orderer




The cert is stored in the cacerts folder in the MSP dir.
Anything else that I’m missing ?

 

 

Best Regards,

Marek Malik

 

Od: Yacov Manevich <YACOVM@...>
Data: piątek, 8 stycznia 2021 22:58
Do: Marek Malik <info@...>
DW: "fabric@..." <fabric@...>
Temat: Re: [Hyperledger Fabric] #fabric-ca #fabric-orderer #hyperledger-fabric Unable to start the Orderer, keep getting "initializing channelconfig failed: could not create channel Consortiums sub-group config:"

 

Put admin certificates in the admin folder, or define the admin OU in the config.yaml of the MSP folder



From:        "Marek Malik" <info@...>
To:        fabric@...
Date:        01/08/2021 11:49 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] #fabric-ca #fabric-orderer #hyperledger-fabric Unable to start the Orderer, keep getting "initializing channelconfig failed: could not create channel Consortiums sub-group config:"
Sent by:        fabric@...





Hello Guys, 

I'm trying to setup my network to work in Kubernetes cluster, but my Orderer keeps failing. I'm getting the following error: 
Main -> PANI 005 Failed validating bootstrap block: initializing channelconfig failed: could not create channel Consortiums sub-group config: setting up the MSP manager failed: administrators must be declared when no admin ou classification is set
panic: Failed validating bootstrap block: initializing channelconfig failed: could not create channel Consortiums sub-group config: setting up the MSP manager failed: administrators must be declared when no admin ou classification is set

Could anyone help?


I'm following a similar setup as the test-network from the samples: I have the Fabric-CA generating the certificates & using the NodeOUs (it is enabled in crypto-config.yaml): 

This is the configtx.yaml that I'm using to generate the genesis.block. It is also located in the msp folder when running the Orderer.

NodeOUs:
   Enable: true
   ClientOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: client
   PeerOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: peer
   AdminOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: admin
   OrdererOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: orderer

Orderer: &OrdererDefaults

 # Orderer Type: The orderer implementation to start
 OrdererType: etcdraft

 Addresses:
   - orderer0.amvox-dlt.io:7050

 # Batch Timeout: The amount of time to wait before creating a batch
 BatchTimeout: 3s

 # Batch Size: Controls the number of messages batched into a block
 BatchSize:

   # Max Message Count: The maximum number of messages to permit in a batch
   MaxMessageCount: 500

   # Absolute Max Bytes: The absolute maximum number of bytes allowed for
   # the serialized messages in a batch.
   AbsoluteMaxBytes: 99 MB

   # Preferred Max Bytes: The preferred maximum number of bytes allowed for
   # the serialized messages in a batch. A message larger than the preferred
   # max bytes will result in a batch larger than preferred max bytes.
   PreferredMaxBytes: 512 KB

 EtcdRaft:
   Consenters:
     - Host: orderer0.amvox-dlt.io
       Port: 7050
       ClientTLSCert: /hlf_config/crypto-config/ordererOrganizations/amvox-dlt.io/orderers/orderer0.amvox-dlt.io/tls/server.crt
       ServerTLSCert: /hlf_config/crypto-config/ordererOrganizations/amvox-dlt.io/orderers/orderer0.amvox-dlt.io/tls/server.crt


 # Organizations is the list of orgs which are defined as participants on
 # the orderer side of the network
 Organizations:

 # Policies defines the set of policies at this level of the config tree
 # For Orderer policies, their canonical path is
 #   /Channel/Orderer/<PolicyName>
 Policies:
   Readers:
     Type: ImplicitMeta
     Rule: "ANY Readers"
   Writers:
     Type: ImplicitMeta
     Rule: "ANY Writers"
   Admins:
     Type: ImplicitMeta
     Rule: "MAJORITY Admins"
   # BlockValidation specifies what signatures must be included in the block
   # from the orderer for the peer to validate it.
   BlockValidation:
     Type: ImplicitMeta
     Rule: "ANY Writers"

 # Capabilities describes the orderer level capabilities, see the
 # dedicated Capabilities section elsewhere in this file for a full
 # description
 Capabilities:
   <<: *OrdererCapabilities

################################################################################
#
#   CHANNEL
#
#   This section defines the values to encode into a config transaction or
#   genesis block for channel related parameters.
#
################################################################################
Channel: &ChannelDefaults
 # Policies defines the set of policies at this level of the config tree
 # For Channel policies, their canonical path is
 #   /Channel/<PolicyName>
 Policies:
   # Who may invoke the 'Deliver' API
   Readers:
     Type: ImplicitMeta
     Rule: "ANY Readers"
   # Who may invoke the 'Broadcast' API
   Writers:
     Type: ImplicitMeta
     Rule: "ANY Writers"
   # By default, who may modify elements at this config level
   Admins:
     Type: ImplicitMeta
     Rule: "MAJORITY Admins"

 # Capabilities describes the channel level capabilities, see the
 # dedicated Capabilities section elsewhere in this file for a full
 # description
 Capabilities:
   <<: *ChannelCapabilities

################################################################################
#
#   Profile
#
#   - Different configuration profiles may be encoded here to be specified
#   as parameters to the configtxgen tool
#
################################################################################
Profiles:

 amvox-channel:
   Consortium: AmvoxConsortium
   <<: *ChannelDefaults
   Application:
     <<: *ApplicationDefaults
     Organizations:
       - *Amvox
       - *Org2
       - *Org3
     Capabilities:
       <<: *ApplicationCapabilities

 OrdererGenesis:
   <<: *ChannelDefaults
   Orderer:
     <<: *OrdererDefaults
     OrdererType: etcdraft
     EtcdRaft:
       Consenters:
         - Host: orderer0.amvox-dlt.io
           Port: 7050
           ClientTLSCert: /hlf_config/crypto-config/ordererOrganizations/amvox-dlt.io/orderers/orderer0.amvox-dlt.io/tls/server.crt
           ServerTLSCert: /hlf_config/crypto-config/ordererOrganizations/amvox-dlt.io/orderers/orderer0.amvox-dlt.io/tls/server.crt
     Addresses:
       - orderer0.amvox-dlt.io:7050

     Organizations:
       - *AmvoxDLT
     Capabilities:
       <<: *OrdererCapabilities

   Application:
     <<: *ApplicationDefaults
     Organizations:
       - <<: *AmvoxDLT

   Consortiums:
     AmvoxConsortium:
       Organizations:
         - *Amvox
         - *Org2
         - *Org3

Anyone has any ideas why ordered can not get started?

 





Re: Unable to Query data from Hyperledger Fabric #couchdb #fabric-chaincode #hyperledger-fabric

chintanr97@...
 

Hi David,

The chaincode is performing a select query on the CouchDB documents, and the fields set for filtering the results are indexed while installing and instantiating the chaincode. The single query using the Fabric Node SDK client might be reading around 20K-30K records. 

We tried by overriding the peer configuration for following default values with the new values: "CORE_CHAINCODE_EXECUTETIMEOUT=300s" and CORE_PEER_KEEPALIVE_CLIENT_TIMEOUT=300s". We also tried with the SDK connection profile using a property:  "grpc.keepalive_timeout_ms": "300000"

So I am not understanding, what we could be missing here. Because the other chaincodes in same channel are able to query the maximum limit of 100K records!

1901 - 1920 of 11324