Does 503(import_only_enabled,api is not available) cause "Unable to connect to peer/orderer"
uqix opened this issue · 14 comments
@uqix That log message is noise we need to fix... that happens because there is some logic that connects to the deployer/operator that's not part of the open source and it is trying to connect to it...
the message you are seeing I believe is because of connectivity issues... perhaps grpc proxy is not setup in front of the peer? You could also look at the network traffic to see if there are not errors and pending requests.
Thanks for the datapoint... that helps... The fact that the version is populated generally means the operations endpoint is functional and the fact that you are able to see the channel means the grpc endpoint is functional.
Do you have more than one peer? If so, can you switch to the different peers and see if there is a difference?
I just setup a test network using the script and I am able to view the peer page
couple of things to check...
-
In Network tab, clear the content and visit the peer page and see what the request, response are. Any errors with deployer should be generally fine. I suspect we will see some failing request or pending request that might help.
FYI... I have these errors (that are benign)
-
In the console tab see if there are any other errors
weird, indeed!
That message comes from the health check... if the healthcheck endpoint didn't respond in 30 seconds that message gets displayed.
Can you check this URL?
<peer_operations_url>/healthz
failed to ping to Docker daemon: cannot connect to Docker endpoint
But we use ccaas instead of Docker.
@uqix This is because of this following line
https://github.com/hyperledger/fabric/blob/release-2.2/sampleconfig/core.yaml#L484
Can you try commenting that out and see if that helps?
We use bevel to deploy the network, no idea how to configure that😂
You might want to open an issue and see how to configure it... Basically, the health endpoint relies on that setting and the Fabric default doesn't quite work for non-docker env.
I commented out endpoint: unix:///var/run/docker.sock
in peer /etc/hyperledger/fabric/core.yaml
, same error:
"failed to ping to Docker daemon: cannot connect to Docker endpoint"
@uqix Can you post the specific call that took time? Is it the call to get the list of components?
I guess because the console thinks peer is not ready yet (reason: "failed to ping to Docker daemon: cannot connect to Docker endpoint"), then it keeps polling healthz
for some while until max retries used out or timed out, finally ProcessProposal
endpoints are called to show peer details which is pretty fast, the long waiting time is taken for polling healthz
not getting ProcessProposal
.
I commented out
endpoint: unix:///var/run/docker.sock
in peer/etc/hyperledger/fabric/core.yaml
, same error:"failed to ping to Docker daemon: cannot connect to Docker endpoint"
My bad, was not aware the env var CORE_VM_ENDPOINT: unix:///host/var/run/docker.sock
is passed by bevel to peer, removing it fixes this issue.
Thanks for your time.