Adds 20250117-actors-pubsub.md #73
Conversation
Signed-off-by: joshvanl <[email protected]>
Signed-off-by: joshvanl <[email protected]>
Signed-off-by: joshvanl <[email protected]>
Is there a proposal for this feature? As it could be considered alongside the desire for true async message passing (inbox / outbox) between Actors, as I outlined here dapr/dapr#501 (comment) |
|
|
||
| ### Actor Subscriptions | ||
|
|
||
| Actors will be able to subscribe to messages within their type for a particular topic. |
There was a problem hiding this comment.
I'd like to see this supplemented with support for content-based routing. While a general broadcast is certainly a much-needed feature, I can easily imagine a chatty topic activating actors unnecessarily. Limiting such activations to only those actors registered to receive that subset would be a solid (and likely expected) part of this functionality.
| This RPC is close to the existing `PublishEvent` rpc, accept that it takes an `actor_type` field rather than a `pubsub_name` field. | ||
| This is because their is 1. only one pubsub associated with actors in that namespace, and 2. the fully qualified topic name is derived via the actor type. | ||
|
|
||
| Publishing messages to actors will not invoke, and therefore initialize the existence of an actor, since an actor needs to be subscribing to a topic to receive messages. |
There was a problem hiding this comment.
I can see a requirement to also initialise an actor - could we have a flag that enables initialisation of an actor first.
The use case here is where the topic name is/contains the ID of the actor so the message is only destined for consumption for that actor id.
If no other actor is subscribed what is the delivery semantics? will it remained queued waiting for the the actor to initialise, subscribe and receive? or does it go straight on the dead letter q. This might also depend on how the the underlying pubsub is configured and delivery semantics At-most-once or at-least-once and i persistent ques are involved? for example using NATS there is much more control over delivery.
|
|
||
| ```yaml | ||
| metadata: | ||
| - name: actorpubsub |
There was a problem hiding this comment.
What is the advantage to have a single pubsub for actors vs allow it to be configured when registering the actor type, so different actor types can run with different pubsubs?
There was a problem hiding this comment.
What happens when two hosts with the same actor types have different pubsubs?
| Actors will be able to subscribe to messages within their type for a particular topic. | ||
| Subscriptions will be dynamically declared, and messages for that topic will be routed through the established bi-directional gRPC stream. | ||
|
|
||
| Upon deactivation, either during shutdown or actor rebalancing, the subscription to all topics by the actor will be removed. |
There was a problem hiding this comment.
It is not clear how rebalancing will work with the subscription. If the subscription is per actor type, how do you handle redirecting the message to the right actor instance?
Also, how to handle subscription to all actorIds (fanout) vs to a single actor ID?
There was a problem hiding this comment.
This may not be as bad, but we do have generally a large number of pods and so the mapping tables could get large.
The same way this is handled with proxying existing requests today.
There was a problem hiding this comment.
Maybe a diagram can help explain this better. Each sidecar instance will read from the message broker, so will they compete for messages and redirect to the right sidecar for each actor id?
|
|
||
| Only one PubSub component can be marked as the actor PubSub. | ||
|
|
||
| ### Actor Subscriptions |
There was a problem hiding this comment.
Maybe we don't need a special subscription. If you add the actor type and id in the cloudevent payload, routing can be done automatically from sidecar without the need of a new API.
@olitomlinson the proposal for the bi-directional stream is here. #72 |
|
|
||
| ### Non-Actor Publishing | ||
|
|
||
| Non-actor clients are able to publish messages to actor subscribers via a new `PublishActorEvent` RPC. |
There was a problem hiding this comment.
I've just realised this is the only way for an Actor to get a message - I had thought that actors could also subscribe to any pubsub topic for a fan out. Not sure how big a deal this is? With current design something would have to rebroadcast a message to the actor pubsub. An extra hop i guess but it in it defence may stop bad actors (pardon the pun) oversubscribing
|
Thank for all the feedback @olitomlinson @yaron2 @theperm @artursouza @WhitWaldo ! Is seems to me to be the case that (at least the first iteration) should instead cover the use case of actors implicitly subscribing to a single actor type topic, where messages are published to an explicit actor ID which are invoked on a defined method. These messages will spawn that actor ID if it does not already exist. Instead of updating this proposal PR, I thought it best to close this one and open a new one- I think this is better for posterity and review. Please don't think I'm ignoring your great feedback! The new proposal over here: #74 |
No description provided.