Hyperledger Fabric v1.2-无法调用链码名称：“ qscc”，错误：执行事务时超时

时间：2018-08-29 03:42:55

标签： hyperledger-fabric hyperledger blockchain

我有3个VM的Fabric网络设置，其中包含4个组织（每个组织2个对等体）以及各自的CouchDB实例，1个专用CA和单个订购者。我使用Hyperledger Java SDK来公开其余的API供消费。

在进行查询时，无论是富文本查询还是有时会遇到以下提到的历史查询例外，我们都经常遇到问题。根据日志，我可以看到用户Chaincode已成功检索查询结果，但在执行“ qscc” Chaincode调用时失败。

2018-08-29 02:43:33.749 UTC [lockbasedtxmgr] Next -> DEBU 26591 queryResultsItr.Next() returned a record:{"availableDate":"","refTxId":"3b9c439f918a4c4ff558ab803611877d5cd990255f57c5b0b2a1944866982384","userId":"ABC0002","updatedBy":"system"}
2018-08-29 02:43:33.749 UTC [chaincode] HandleGetQueryResult -> DEBU 26592 Got keys and values. Sending RESPONSE
2018-08-29 02:43:33.749 UTC [chaincode] HandleTransaction -> DEBU 26593 [4e6c0cc5] Completed GET_QUERY_RESULT. Sending RESPONSE
2018-08-29 02:43:33.750 UTC [chaincode] handleMessage -> DEBU 26594 [4e6c0cc5] Fabric side handling ChaincodeMessage of type: QUERY_STATE_CLOSE in state ready
2018-08-29 02:43:33.750 UTC [chaincode] HandleTransaction -> DEBU 26595 [4e6c0cc5] handling QUERY_STATE_CLOSE from chaincode
2018-08-29 02:43:33.750 UTC [chaincode] HandleTransaction -> DEBU 26596 [4e6c0cc5] Completed QUERY_STATE_CLOSE. Sending RESPONSE
2018-08-29 02:43:33.751 UTC [chaincode] handleMessage -> DEBU 26597 [4e6c0cc5] Fabric side handling ChaincodeMessage of type: COMPLETED in state ready
2018-08-29 02:43:33.751 UTC [chaincode] Notify -> DEBU 26598 [4e6c0cc5] notifying Txid:4e6c0cc5d95c5686c20d33d6bafa2cf850b1d1615f240c56831c44cf5bb69c79, channelID:mychannel
2018-08-29 02:43:33.751 UTC [chaincode] Execute -> DEBU 26599 Exit
2018-08-29 02:43:33.751 UTC [endorser] callChaincode -> DEBU 2659a [mychannel][4e6c0cc5d95c5686c20d33d6bafa2cf850b1d1615f240c56831c44cf5bb69c79] Exit
2018-08-29 02:43:33.751 UTC [lockbasedtxmgr] GetTxSimulationResults -> DEBU 2659b Simulation completed, getting simulation results
2018-08-29 02:43:33.751 UTC [lockbasedtxmgr] Done -> DEBU 2659c Done with transaction simulation / query execution [4e6c0cc5d95c5686c20d33d6bafa2cf850b1d1615f240c56831c44cf5bb69c79]
2018-08-29 02:43:33.751 UTC [endorser] SimulateProposal -> DEBU 2659d [mychannel][4e6c0cc5] Exit
2018-08-29 02:43:33.751 UTC [endorser] endorseProposal -> DEBU 2659e [mychannel][4e6c0cc5] Entry chaincode: name:"mychaincode"
2018-08-29 02:43:33.751 UTC [endorser] endorseProposal -> DEBU 2659f [mychannel][4e6c0cc5] escc for chaincode name:"mychaincode"  is escc
2018-08-29 02:43:33.751 UTC [endorser] EndorseWithPlugin -> DEBU 265a0 Entering endorsement for {plugin: escc, channel: mychannel, tx: 4e6c0cc5d95c5686c20d33d6bafa2cf850b1d1615f240c56831c44cf5bb69c79, chaincode: mychaincode}
2018-08-29 02:43:33.751 UTC [endorser] EndorseWithPlugin -> DEBU 265a1 Exiting {plugin: escc, channel: mychannel, tx: 4e6c0cc5d95c5686c20d33d6bafa2cf850b1d1615f240c56831c44cf5bb69c79, chaincode: mychaincode}
2018-08-29 02:43:33.751 UTC [endorser] endorseProposal -> DEBU 265a2 [mychannel][4e6c0cc5] Exit
2018-08-29 02:43:33.751 UTC [lockbasedtxmgr] Done -> DEBU 265a3 Done with transaction simulation / query execution [4e6c0cc5d95c5686c20d33d6bafa2cf850b1d1615f240c56831c44cf5bb69c79]
2018-08-29 02:43:33.751 UTC [endorser] ProcessProposal -> DEBU 265a4 Exit: request from 10.255.0.4:47828
2018-08-29 02:43:33.977 UTC [gossip/discovery] periodicalSendAlive -> DEBU 265a5 Sleeping 5s
2018-08-29 02:43:34.198 UTC [gossip/discovery] periodicalReconnectToDead -> DEBU 265a6 Sleeping 25s
2018-08-29 02:43:34.711 UTC [gossip/election] waitForInterrupt -> DEBU 265a7 [40 227 139 114 173 5 75 157 49 97 134 49 223 250 188 122 25 48 140 50 245 198 39 79 233 243 124 193 89 118 85 88] : Exiting
2018-08-29 02:43:34.711 UTC [gossip/election] IsLeader -> DEBU 265a8 [40 227 139 114 173 5 75 157 49 97 134 49 223 250 188 122 25 48 140 50 245 198 39 79 233 243 124 193 89 118 85 88] : Returning true
2018-08-29 02:43:34.711 UTC [gossip/election] waitForInterrupt -> DEBU 265a9 [40 227 139 114 173 5 75 157 49 97 134 49 223 250 188 122 25 48 140 50 245 198 39 79 233 243 124 193 89 118 85 88] : Entering
2018-08-29 02:43:35.075 UTC [chaincode] Execute -> DEBU 265aa Exit
2018-08-29 02:43:35.075 UTC [endorser] callChaincode -> DEBU 265ab [mychannel][8fb2e3710e44df19e8255177885c5ce29a940ea5239b20e7a94791fe2e4faee9] Exit
2018-08-29 02:43:35.077 UTC [endorser] SimulateProposal -> ERRO 265ac [mychannel][8fb2e371] failed to invoke chaincode name:"qscc" , error: timeout expired while executing transaction
github.com/hyperledger/fabric/core/chaincode.(*Handler).Execute
        /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:919
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).execute
        /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:253
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Invoke
        /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:239
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
        /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:179
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
        /opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:141
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
        /opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:136
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
        /opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
        /opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
        /opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
        /opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
        /opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
        /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
        /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
        /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
        /opt/go/src/runtime/asm_amd64.s:2361
error sending
failed to execute transaction 8fb2e3710e44df19e8255177885c5ce29a940ea5239b20e7a94791fe2e4faee9
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
        /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:181
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
        /opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:141
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
        /opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:136
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
        /opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
        /opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
        /opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
        /opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
        /opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
        /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
        /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
        /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
        /opt/go/src/runtime/asm_amd64.s:2361
2018-08-29 02:43:35.077 UTC [endorser] SimulateProposal -> DEBU 265ad [mychannel][8fb2e371] Exit
2018-08-29 02:43:35.077 UTC [endorser] ProcessProposal -> DEBU 265ae Exit: request from 10.255.0.4:47818

1 个答案:

答案 0 :(得分：2)

我最近也遇到了这个问题。在检查了一些相关问题和文档之后，对我来说，临时解决方案是重新启动您在其日志中找到Failed to invoke chaincode name "qscc"的对等方：

docker restart <peer container's id>

但是，此解决方案无法完全解决问题。但是您可以检查this issues以获得更多信息（问题this重复存在，但仍未解决）。

以下是Manish Sethi的相关评论，以解释查询分类账背后发生的事情：

  

Ledger公开了两组API，一组API与状态读取和操作有关，而另一组API与查询区块链状态有关（例如GetBlockByNumber和GetTransactionByID）。第一组API通过交易模拟器公开（用于在交易模拟过程中使用的链码），第二组API在分类账界面中作为直接API公开（供客户了解分类帐状态） ）。

     

请牢记上述内容，分类帐设计中的一个默认假设是，单个分类限制将其用法专门限制为上述一组API中的一种。链码将其自身限制为与状态相关的API，并且账本状态查询客户端无需创建模拟器。

     

但是，由于在更高层上，与账本状态相关的API是通过链码（具体来说为qscc）公开的，因此上述假设被打破了。回答分类帐状态查询的执行路径在到达qscc代码（实际上没有使用交易模拟器）之前获得一个交易模拟器。

     

更具体地说，对这两组API的附加约束涉及以下事实：对任何分类账API的两个独立外部调用应给块存储和状态一个原子提交的感知概念。例如，如果客户端查询API GetBlockchainInfo并发现已提交块号10，则不会发生这种情况，但是当他提交后续状态查询时，该查询将返回块9的状态（因为状态为区块10的更新仍在进行中）。这是通过一对锁实现的。一个锁在仿真和声明的b提交之间同步状态，另一个锁将与总帐状态相关的调用与整个提交同步。这样做的目的是通过将模拟停止到最低限度（仅在将更新实际转储到磁盘时），以达到更好的性能，但要以与分类帐状态相关的查询为代价。因为qscc采用了事务模拟器，所以上面提到的交互导致了报告的死锁。我相信，今后的建议之一是通过grpc接口公开这些分类账状态相关的API，这将解决此问题。但是，出于完整性考虑，我在下面列出了三个选项...

     

qscc路径不占用事务模拟器（否则也是需要的，因为事务模拟器是一种昂贵的资源，因为它需要对statusb进行读锁定才能与提交同步，因此仅应用于事务模拟）。

     

另一种解决方法可能是通过更粗略的单锁来实现上述感知到的原子提交到块存储和状态的概念，但这会影响吞吐量，这不是理想的解决方案。

     

实现感知到的原子提交的概念仍然有所不同..这需要在分类帐存储和所述b之间的交互中进行大量工作。在坚果壳中，将分类帐存储暴露为两阶段提交。第一步，我们附加该块，然后在第二步中，更新BlockchainInfo和与所述的b更新同步的blockindex。   鉴于以上所述，由于无论如何都需要第一个，我的建议是将其固定为1.1和1.2。

相关问题
最新问题