Can not find service @ example "invoke-simple"

[JochenKienzle]

Hello,

I'm currently trying out dapr for python. I started with the pub-sub simple example and its working fine.

Now, I got stuck with the invoke-simple example.

I start the apps with the following commands and order:

1. dapr run --app-id invoke-receiver --app-protocol grpc --app-port 50051 python invoke-receiver.py
2. dapr run --app-id invoke-caller --app-protocol grpc python invoke-caller.py

Afterwards, invoke-caller.py gives me the following error:

[94;1m== APP == grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
[0m
[94;1m== APP ==        status = StatusCode.UNKNOWN
[0m
[94;1m== APP ==        details = "couldn't find service: invoke-receiver"
[0m
[94;1m== APP ==        debug_error_string = "{"created":"@1606122049.322000000","description":"Error received from peer ipv4:127.0.0.1:3128","file":"src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"couldn't find service: invoke-receiver","grpc_status":2}"

For me, it looks a little bit strange why it receives an error from my proxy (127.0.0.1:3128). Could it be some proxy issues? Do I need to add something to "no-proxy" for dapr? (Currently: no_proxy: .docker.internal,localhost,127.0.0.1)

Could you help me to get this example running?

[youngbupark]

it works for me on my machine. did you run this sample inside docker container? which version of dapr runtime are you using?

[JochenKienzle]

Thanks for testing @youngbupark

Thats my current setup:

PS D:\> dapr --version
CLI version: 0.11.0
Runtime version: 0.11.3

Output of pip freeze:
dapr==0.7.0a0
dapr-dev==0.8.0a0.dev267
dapr-ext-fastapi-dev==0.8.0a0.dev267
dapr-ext-grpc==0.7.0a0

[youngbupark]

Please delete all packages first and install only non dev pkgs :) *-dev suffix pkgs are the development build :)

If you checkout master branch, then all examples will use dev pkgs.

Output of pip freeze:
dapr==0.7.0a0
dapr-dev==0.8.0a0.dev267
dapr-ext-fastapi-dev==0.8.0a0.dev267
dapr-ext-grpc==0.7.0a0

Please checkout the version v0.8.0a0 tag and use the example for the latest dapr pkg (non-dev)- https://github.com/dapr/python-sdk/tree/v0.8.0a0/examples/invoke-simple

0.8.0a0 should work with 0.11.3 Dapr but try with the latest 1.0.0-rc.1 Dapr as well.

dapr uninstall --all

curl -fsSL https://raw.githubusercontent.com/dapr/cli/master/install/install.sh | /bin/bash -s 1.0.0-rc.2

dapr init --runtime-version=1.0.0-rc.1

[JochenKienzle]

Thanks for your reply.

with dapr 1.0.1-rc.1 I'm getting the following error:

PS [...]\python-sdk\examples\pubsub-simple> dapr run --app-id python-subscriber --app-protocol grpc --app-port 50051 python.exe subscriber.py
Starting Dapr with id python-subscriber. HTTP Port: 13296. gRPC Port: 13297
�[93;1m== DAPR == flag provided but not defined: -max-concurrency

and stopped working printing all the possible flags. Adding --max-concurrency 1 doesn't help.

My python libs (pip3 freeze):

dapr==0.8.0a0
dapr-ext-fastapi==0.8.0a0
dapr-ext-grpc==0.8.0a0

Next, I will test it with dapr 0.11.3

[JochenKienzle]

With 0.11.3 the --max concurrency issue doesn't appear but I get the same error as before:

�[94;1m== APP == grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
�[0m
�[94;1m== APP ==        status = StatusCode.UNKNOWN
�[0m
�[94;1m== APP ==        details = "couldn't find service: invoke-receiver"
�[0m
�[94;1m== APP ==        debug_error_string = "{"created":"@1606735341.397000000","description":"Error received from peer ipv4:127.0.0.1:3128","file":"src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"couldn't find service: invoke-receiver","grpc_status":2}"

I still assume that this might be related to the proxy configuration, as is still receives it from 127.0.0.1:3218 (which is the proxy port for http/https) but as I said, localhost is whitelisted. Maybe another address (multicast) is involved here?

[youngbupark]

With 0.11.3 the --max concurrency issue doesn't appear but I get the same error as before:

Seems like you install older version of dapr runtime. there is breaking change between 0.11.3 and 1.0.0-rc.1.

�[94;1m== APP == grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
�[0m
�[94;1m== APP ==        status = StatusCode.UNKNOWN
�[0m
�[94;1m== APP ==        details = "couldn't find service: invoke-receiver"
�[0m
�[94;1m== APP ==        debug_error_string = "{"created":"@1606735341.397000000","description":"Error received from peer ipv4:127.0.0.1:3128","file":"src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"couldn't find service: invoke-receiver","grpc_status":2}"

I still assume that this might be related to the proxy configuration, as is still receives it from 127.0.0.1:3218 (which is the proxy port for http/https) but as I said, localhost is whitelisted. Maybe another address (multicast) is involved here?

Did you whitelist 127.0.0.1 or localhost in windows ? by default windows resolves localhost to ipv6 localhost address, not ipv4. please ensure that your firewall whitelisted 127.0.0.1.

[JochenKienzle]

Proxy has a pass-through for 127.0.0.* and localhost. I have found out, that the env-variable http_proxy is used (if I change it, the related address and port is changed in the error message as well). Is there any kind of http(s) communication used by grpc for binding methods (e.g. discovery)?

[youngbupark]

Proxy has a pass-through for 127.0.0.* and localhost. I have found out, that the env-variable http_proxy is used (if I change it, the related address and port is changed in the error message as well).

I do not know where http_proxy environment variable is used in Dapr.

Is there any kind of http(s) communication used by grpc for binding methods (e.g. discovery)?

I am not sure that I understand your question correctly. python-sdk doesn't use any http.

When you try this hello world example, did you see the same issue?

[JochenKienzle]

Good hint, I tried out the hello world example and it doesn't work as well:

dapr run --app-id nodeapp --app-port 3000 --dapr-http-port 3500 node app.js
Starting Dapr with id nodeapp. HTTP Port: 3500. gRPC Port: 14790
[...]
Updating metadata for app command: node app.js
You're up and running! Both Dapr and your app logs will appear here.

dapr invoke --app-id nodeapp --method neworder --payload "{\"data\": { \"orderId\": \"42\" } }"
{"errorCode":"ERR_DIRECT_INVOKE","message":"couldn't find service: nodeapp"}
App invoked successfully

I double checked my proxy settings in docker as well on my proxy on my system. Both pass-through localhost & 127.0.0.1 and as I said, pub-sub example is working fine.

[JochenKienzle]

Some update:
I tried on a Linux VM which uses the same proxy setup --> It works.

[wcs1only]

So we've had some reports that certain anti-virus/security software may block mdns requests (which is what dapr uses for service discovery when running locally). If you are still having this issue, can you let us know what OS version you are running on, and if you have any antivirus/security software running?

[JohnH-Work]

So we've had some reports that certain anti-virus/security software may block mdns requests (which is what dapr uses for service discovery when running locally). If you are still having this issue, can you let us know what OS version you are running on, and if you have any antivirus/security software running?

I'm getting this issue running the hello world example, but it works if I disable the VPN client (AppGate SDP). I'm running on Windows 10 (20H2) with McAfee antivirus (disabling that made no difference). The VPN is required for remote working, so it's less than ideal.

[JochenKienzle]

I have security software running on Windows and Linux so this could causing the issues with service discovery and rpcs. I was working using a VPN and without, which made no difference (but I was using dapr on localhost only).

On Linux, Service discovery and pub-sub was working but rpcs haven't been executed (timeout). I have to check your suggestions and to double check my setup. I'll let you know if I have some new information.

[wcs1only]

Closing this, since there is nothing python-sdk specific to be done. We do have a runtime issue open for this dapr/dapr#3256.