We are using the IBM Managed Blockchain based on fabric 1.2, and using the Go SDK @5e291d3a34f59beb9a8ae2bcbba388515648dc73. When we try to invoke the chaincode we have installed on the peers, we get a "no peers to connect to" error:
[fabsdk/fab] 2019/01/25 12:25:57 UTC - dispatcher.(*Dispatcher).Start.func1 -> DEBU Listening for events...
[fabsdk/fab] 2019/01/25 12:25:57 UTC - client.(*Client).connect -> DEBU ... got error in connection response: no peers to connect to
[fabsdk/common] 2019/01/25 12:25:57 UTC - retry.(*RetryableInvoker).Invoke -> DEBU Failed with err [error registering for TxStatus event: no peers to connect to] on attempt #1. Checking if retry is warranted...
[fabsdk/util] 2019/01/25 12:25:57 UTC - lazyref.(*Reference).setTimerRunning -> DEBU Timer started
[fabsdk/common] 2019/01/25 12:25:57 UTC - retry.(*RetryableInvoker).Invoke -> DEBU ... retry for err [error registering for TxStatus event: no peers to connect to] is NOT warranted after 1 attempt(s).
[fabsdk/util] 2019/01/25 12:25:57 UTC - lazyref.checkTimeStarted -> DEBU Starting timer
After putting some extra logging of our own it looks like the failure happens because the peer discovery service (https://github.com/hyperledger/fabric-sdk-go/blob/master/pkg/client/common/discovery/dynamicdiscovery/chservice.go#L72) doesn't return any peers in its response. The targets seem to be set correctly.
After dumping the GRPC response, we get
(*discovery.Response)(0xc4205cd600)(
results: <
members: <
peers_by_org: <
key: "org1"
value: <>
>
>
>
)
We also set up a different fabric network on our own with the same chaincode, which works properly and the same dump shows this instead (some parts were redacted):
(*discovery.Response)(0xc42045ed20)(
results: <
members: <
peers_by_org: <
key: "Org1MSP"
value: <
peers: <
state_info: <
payload:"<redacted>"
>
membership_info: <payload:"<redacted>" >
identity:"<redacted>"
>
peers: <
state_info: <
payload:"<redacted>"
signature:"<redacted>"
>
membership_info: <
payload:"<redacted>"
signature:"<redacted>"
>
identity:"<redacted>"
>
>
>
peers_by_org: <
key:"Org2MSP"
value: <
peers: <
state_info:<
payload:"<redacted>"
signature:"<redacted>"
>
membership_info: <
payload:"<redacted>"
>
identity:"<redacted>"
>
peers: <
state_info: <
payload:"<redacted>"
signature:"<redacted>"
>
membership_info: <
payload:"<redacted>"
signature:"<redacted>"
>
identity:"<redacted>"
>
>
>
>
>
)
I am unsure if the issue is in the configuration of the SDK or the IBM Managed fabric network. If it is the IBM network, then it seems that somehow the peers aren't aware that they are members of an organization.
Has anyone seen this behaviour before? I searched the hyperledger official rocket chat for the "no peers to connect to" error, and some results came up, but they seemed to be caused by other reasons, such as the peers being excluded by the SDK, not due to the response to the discovery request.
Make sure you have anchor peers configured in the channel.
Make sure the peers have external endpoints configured, i.e - (CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1.org1.example.com:7051)
我在使用sdk实例化链码时也遇到了这个问题,在进入peer容器 echo $CORE_PEER_GOSSIP_EXTERNALENDPOINT 时,发现是我的节点地址指定错误了。使用正确的节点地址就能够实例化成功了。谢谢~