dapr: Show correct error message when trying to use actors without specifying an app-port.
When I try to run actor I received the flow message even with statestore configured with actorStateStore value true.
{ "errorCode": "ERR_ACTOR_RUNTIME_NOT_FOUND", "message": "the state store is not configured to use the actor runtime. Have you set the - name: actorStateStore value: \"true\" in your state store component file?" }
So I have this component:
apiVersion: dapr.io/v1alpha1 kind: Component metadata: name: statestore spec: type: state.redis version: v1 metadata:
- name: redisHost value: localhost:6379
- name: redisPassword value: “”
- name: actorStateStore value: “true”
I’m missing any configuration?
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 1
- Comments: 17 (4 by maintainers)
Ran into that same issue setting up a poc project. On my end problem was the port you specify when running dapr needs to match the port asp is running on:
dapr run --app-id myapp --app-port 5028 --dapr-http-port 3500 -- dotnet run --urls "http://*:5028"“I am sorry to see this has been your experience. However, as the correspondence on this issue shows, there isn’t actually a bug to fix in terms of actor functionality and once setting up the correct app port, the situation resolves.”
I literally fiddled with settings for a week, including tweaks to network_mode and app port.
@maxpu80 provided a full sample where it looks like he’s setting the app port.
I appreciate you guys taking the time, but can someone PLEASE provide a working sample of service communicating with an actor running via docker compose, i.e. I can download it, extract it, load it in Visual studio, hit F5? For someone with experience with DAPR it ought to take them less than 10 minutes to create it.
I’ve dug into this issue deeper. The error message “the state store is not configured to use the actor runtime” is clearly a red herring. As others have commented, you need to be sure you’ve got the --app-port correct, and what this hints at, is that if the sidecar isn’t able to communicate with its related service, it gives the really poor state store error. In my case I’ve got serviceA attempting to communicate with an actor service (serviceB). When I attempt to use the actor proxy in serviceA, I get the state store error, so I tried making some basic http calls (via HttpClient) just prior to using the proxy, and I got some interesting results.
Calling http://serviceB:5402, I get a successful response Calling http://localhost:3500/v1.0/actors/MyActorName/ARandomId/reminders/rk, the response contains the state store error Calling http://localhost:5402 I get “Cannot assign requested address” Calling http://127.0.0.1 I get Connection refused
The last one is somewhat interesting, if I retrieve http://127.0.0.1 in a browser, I get a successful response. Without digging into the dapr code, it seems like the sidecar, when launched via VisualStudio / docker-compose.yml, is attempting to communicate with its associated service using http://localhost or http://127.0.0.1, instead of http://app-Id:app-Port.
A couple extra notes for clarity.
I see the following during startup, so I’m pretty sure the statestore is being properly configured. time=“2022-11-13T19:18:56.1030189Z” level=info msg=“component loaded. name: statestore, type: state.in-memory/v1” app_id=myappname instance=aa8cada5224e scope=dapr.runtime type=log ver=1.9.0
I switched to in-memory state store just to reduce one potential source of errors, but see the exact same behavior when using the redis state store.
This should not be marked as stale. I’ve been losing my mind for the last five days trying to get an actor to work using docker-compose. I finally stumbled upon this issue.
@maxpu80 Did you ever have any success? I’ve tested with the lastest Docker and Dapr NuGets with no success.