Actors: PubSub #74
Actors: PubSub #74
Conversation
Signed-off-by: joshvanl <[email protected]>
|
cc @theperm |
Signed-off-by: joshvanl <[email protected]>
Signed-off-by: joshvanl <[email protected]>
| This proposal introduces PubSub capabilities for Dapr Actors, enabling actors to subscribe to messages for their actor type. | ||
| Additionally, actors of a that type have the ability to publish messages to that type, to be delivered to particular actor IDs. | ||
| A single designated PubSub component will be marked as the actor PubSub for that namespace, similar to how an actor state store is defined. | ||
| There can be only one actor PubSub Component per namespace. |
There was a problem hiding this comment.
While having a means to set up a standing subscription like this is useful to subscribe all actors of a given type, I'd also like to see actors able to set up something similar to streaming subscriptions in which specific actor instances of a type can subscribe to a named pubsub component type, a variable topic name and assign their own filter (filtered at the runtime) so the actor is only activated on a match.
There was a problem hiding this comment.
Opening up the possibility for a streaming connection per actor ID that outlives the actor instance itself makes me a little bit uncomfortable. We should look into how this would scale.
|
|
||
| Today, Dapr provides PubSub functionality for applications but lacks native PubSub integration for actors. | ||
| This limitation means that actors cannot communicate efficiently via publish-subscribe messaging patterns within their type. | ||
| By enabling Actor PubSub, actors can publish messages to specific actor IDs, improving scalability and communication reliability. |
There was a problem hiding this comment.
Circling back to my other comment, having a more dynamic subscription would enable an actor to far more easily subscribe to messages from other actor types altogether (huge for scenarios where an actor "manager" is responsible for cross-domain activities).
In light of line 24, I'll write a separate proposal.
|
|
||
| ### Component | ||
|
|
||
| A single PubSub component will be designated as the actor PubSub, similar to how an actor state store is configured. |
There was a problem hiding this comment.
I'm not a huge fan of this as:
- I feel it really limits potential pubsub applications for Dapr Actors to inter-type reliable messaging instead of of allowing actors to respond to events happening across the rest of the deployed apps
- It forces me to use a single pubsub provider for all actors across a solution (requiring that I split up projects to deploy with different components files for each) and potentially running into quota limits (e.g. 5k active connections on Azure Service Bus), which, across multiple actor Apps, might be hit rather quickly.
|
|
||
| ### Event Message Routing | ||
|
|
||
| Upon the Daprd runtime receiving an actor PubSub message, the runtime will wrap the message with a CloudEvent envelope as usual. |
There was a problem hiding this comment.
I'm entirely in favor of Cloud events being necessary so routing is feasible.
| The method field will be used to invoke the actor at that method with the data payload. | ||
| The result of that invocation will determine the response code sent back to the PubSub broker component. | ||
|
|
||
| All Daprds who share a hosted actor type will subscribe to the same PubSub topic. |
There was a problem hiding this comment.
I would still love to see routing here, specifically so some inbound event doesn't activate every virtual actor that's ever been and ever will be when only three of them cared about the content.
There was a problem hiding this comment.
If an actor controlled the subscription to the actor type topic or any topic for that matter, it might allow for that actor to expire but still maintain the subscription for it to be reinvoked and brought back to life. The actor would have to be responsible for unsubcribing in the future or we could put a TTL on the subscription itself so it can clean up after a period of time if that was desirable.
| Proxying requests like this is already implemented and used in the actor runtime engine today, so no work needs to be added to support this. | ||
|
|
||
| SDKs will need to be updated to support publishing actor PubSub messages. | ||
| No changes to SDKs need to be made to support _receiving_ actor PubSub messages. |
There was a problem hiding this comment.
I don't know about this - at least .NET would need to know about the start/end of the turn for reentrancy and state cache purposes.
| These messages will be routed (proxied) to the correct daprd host, based on the placement table hash. | ||
| Proxying requests like this is already implemented and used in the actor runtime engine today, so no work needs to be added to support this. | ||
|
|
||
| SDKs will need to be updated to support publishing actor PubSub messages. |
| ``` | ||
|
|
||
| Upon the daprd runtime receiving an actor PubSub message, the runtime will unwrap the CloudEvent envelope and route the message to the appropriate actor instance. | ||
| The actor type and ID to route is easily extracted from the topic the message was received from, and the ID from the CloudEvent envelope. |
There was a problem hiding this comment.
This appears to only cater for direct actor id delivery, how can we delver to all actors of a type? omit the ID? THe there are 2 scenarios, as WhitWaldo states, current Actors that are alive, every other actor that did or will exist. Probably not feasible to cater for the latter.
There was a problem hiding this comment.
Orleans handles the latter (in conjunction with pubsub providers that support token offsets) by making the whole of the stream available from the beginning (with a token) or the last received (without) to any new actor instances that show up. That way, there's no expectation that the messages be kept in perpetuity for instances that don't exist yet, but the subscription is implicitly created when the instance is called into existence.
There was a problem hiding this comment.
This is indeed possible with some supported pubsub components (eg. stream-log brokers like Redis, Kafka) but messages in other components (like Pulsar or RabbitMQ for example) are removed from the queue when acknowledged. If we go this route docs should make it clear which pubsub components support it.
| type: pubsub.joshvanl | ||
| version: v1 | ||
| metadata: | ||
| - name: actorpubsub # Added metadata field for all PubSubs. |
There was a problem hiding this comment.
Generally, Im ok with this proposal as a starting point to be expanded upon. Just a few clarification questions:
Could you provide an example or 2 for this feature from an end user perspective and corresponding diagram depicting it in action?
Does the actorPubSub inherit the pubsub resiliency policies if available or do we need a resiliency policy for this? I see we have a pubsub and actor target.
Similarly, what happens with in-flight messages if an actor instance is deactivated while processing? Should actor deactivation wait for in-flight messages to complete?
| ## Overview | ||
|
|
||
| This proposal introduces PubSub capabilities for Dapr Actors, enabling actors to subscribe to messages for their actor type. | ||
| Additionally, actors of a that type have the ability to publish messages to that type, to be delivered to particular actor IDs. |
There was a problem hiding this comment.
Is there a reason we're limiting messaging to actors of the same type? I think we should consider cross-actor and app to actor communication as well.
| ``` | ||
|
|
||
| Upon the daprd runtime receiving an actor PubSub message, the runtime will unwrap the CloudEvent envelope and route the message to the appropriate actor instance. | ||
| The actor type and ID to route is easily extracted from the topic the message was received from, and the ID from the CloudEvent envelope. |
There was a problem hiding this comment.
This is indeed possible with some supported pubsub components (eg. stream-log brokers like Redis, Kafka) but messages in other components (like Pulsar or RabbitMQ for example) are removed from the queue when acknowledged. If we go this route docs should make it clear which pubsub components support it.
| This proposal introduces PubSub capabilities for Dapr Actors, enabling actors to subscribe to messages for their actor type. | ||
| Additionally, actors of a that type have the ability to publish messages to that type, to be delivered to particular actor IDs. | ||
| A single designated PubSub component will be marked as the actor PubSub for that namespace, similar to how an actor state store is defined. | ||
| There can be only one actor PubSub Component per namespace. |
There was a problem hiding this comment.
Opening up the possibility for a streaming connection per actor ID that outlives the actor instance itself makes me a little bit uncomfortable. We should look into how this would scale.
|
|
||
| This proposal introduces PubSub capabilities for Dapr Actors, enabling actors to subscribe to messages for their actor type. | ||
| Additionally, actors of a that type have the ability to publish messages to that type, to be delivered to particular actor IDs. | ||
| A single designated PubSub component will be marked as the actor PubSub for that namespace, similar to how an actor state store is defined. |
There was a problem hiding this comment.
What's the reason for only allowing one pubsub/statestore per namespace? Could this limit scaling or have more granular storage isolation?
| To facilitate publishing a message to a actor ID, the following client API will be added to the Dapr runtime. | ||
| Notice that the message type is similar to the [existing PublishEvent API](https://github.com/dapr/dapr/blob/955436f45f783e52c9af8c2ae32f7f82a287c39c/dapr/proto/runtime/v1/dapr.proto#L381), but with fields dedicated to actor routing and endpoint invocation. | ||
| The metadata field will have the same functionality and uses as the [existing PublishEvent API](https://github.com/dapr/dapr/blob/955436f45f783e52c9af8c2ae32f7f82a287c39c/dapr/proto/runtime/v1/dapr.proto#L381). | ||
| A client does not need to be an actor or host that actor type to use this API. |
There was a problem hiding this comment.
how will authz work on this endpoint?
|
+1 binding |
Supersedes #73