【发布时间】：2019-09-08 00:58:55
【问题描述】：
实例化命令成功完成，但在分析对等日志时，您可能会注意到：
2019-04-17 17:25:52.581 UTC [gossip.state] commitBlock -> DEBU 48c [canal-contrato] 已提交区块 [1] 与 1 个交易
2019-04-17 17:25:52.581 UTC [common.deliver] DeliverBlocks -> DEBU 48d [channel: canal-contrato] 为 192.168.16.1:48230 交付块 (0xc00023f9c0)
2019-04-17 17:25:52.581 UTC [fsblkstorage] waitForBlock -> DEBU 48e 将等待更新的块。 maxAvailaBlockNumber=[1], waitForBlockNum=[2]
2019-04-17 17:25:52.586 UTC [common.deliver] DeliverBlocks -> DEBU 48f 上下文取消，中止等待下一个块
2019-04-17 17:25:52.586 UTC [common.deliverevents] func1 -> DEBU 490 关闭交付流
2019-04-17 17:25:52.586 UTC [comm.grpc.server] 1 -> INFO 491 流式调用已完成 {"grpc.start_time": "2019-04-17T17:25:50.441Z "，"grpc.service"："protos.Deliver"，"grpc.method"："DeliverFiltered"，"grpc.peer_address"："192.168.16.1:48230"，"error"："上下文在块检索前完成：上下文取消”，“grpc.code”：“未知”，“grpc.call_duration”：“2.144399922s”}
谁能告诉我我可能做错了什么以及这个错误的后果是什么？
注意事项：
- orderer 日志不显示任何类型的错误
- 所有容器运行正常
- 我使用的是节点版本 8.9.0（使用 npm 5.5.1）
- 我有 1 个组织，有 1 个同行、1 个 CA 和 1 个已订购（仅用于测试）
- 我使用的是 hyperlegder fabric 1.4 版
【问题讨论】：
-
我认为您需要检查上下文超时。查找使用
context.WithTimeout()的代码片段。 -
如果你正在开发这段代码，你需要搜索客户端向服务器执行GRPC请求的地方。每个 GRPC 请求都有一个上下文，因此您需要检查谁在为这些上下文设置超时。并且可能会增加这些超时时间。
-
抱歉这个菜鸟问题，但我想在哪里进行这种可能的修改？我遵循平衡转移示例（fabric-samples）之类的结构，但在 node.js 中部署了链代码。
-
恐怕我无法回答这个问题，因为我不是超级账本用户。如果您作为系统工程师或 devops 而不是开发人员使用此软件，请尝试分析配置文件。也许有超时设置。看起来请求在 2 秒后超时（从您的日志中可以看出）。
标签： hyperledger-fabric instantiation grpc grpc-go chaincode