1

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.

e.nikolov
  • 127
  • 1
  • 11

1 Answers1

1
  1. Make sure you have anchor peers configured in the channel.

  2. Make sure the peers have external endpoints configured, i.e - (CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1.org1.example.com:7051)

yacovm
  • 5,120
  • 1
  • 11
  • 21
  • 1
    Thanks for your response. Should this be set on the machine that runs the peer? If so, I'm not sure how to set it in the IBM blockchain. We don't get direct access to the machines, everything happens via their GUI, and I haven't seen a setting for anchor peers. – e.nikolov Jan 25 '19 at 22:25
  • anchor peers are set in the channel config. external endpoints are via the env vars of the peers. – yacovm Jan 26 '19 at 09:39
  • @yacovm to our knowledge you cannot set env variables in the IBM Cloud/Blockchain GUI, how do you do this? Or is this not possible with IBM Blockchain? – jvdp Jan 28 '19 at 09:47