Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ActorSystem local registry for topics #31053

Closed
johanandren opened this issue Jan 10, 2022 · 3 comments
Closed

ActorSystem local registry for topics #31053

johanandren opened this issue Jan 10, 2022 · 3 comments
Assignees
Labels
1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted t:typed
Milestone

Comments

@johanandren
Copy link
Member

The current topic API expects users to spawn and keep track of their topics themselves (multiple instances of the same topic in the same actor system is allowed).

Often when using topics, in a clustered app, I expect that you are after one topic actor instance per node and topic. Implementing that isn't a lot of work but it could be nice with an extension spawning topics making sure the same topic only spawns one actor, and that the protocol is the same (at runtime), something like:

val topic: ActorRef[T] = PubSubTopics(system).topic[T](name)
@johanandren johanandren added 0 - new Ticket is unclear on it's purpose or if it is valid or not t:typed labels Jan 10, 2022
@patriknw
Copy link
Member

I think that would be nice.

@patriknw patriknw added 1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted and removed 0 - new Ticket is unclear on it's purpose or if it is valid or not labels Jan 11, 2022
@johanandren
Copy link
Member Author

Another use case where this would be useful:

Imagine a HTTP or gRPC endpoint where clients subscribe and publish to a topic with more or less dynamic topic names (let's say potentially infinite over time) sent by the clients. We'd want many clients subscribing for the same topic to only mean a published message is sent to the node twice. We also don't want each client connecting to do a one off publish to have to wait for the list of subscribers from the receptionist before publishing.

For this we'd need such a registry and a also add Topic actor TTL, counted after last subscriber unsubscribes or a message is published. That way the short lived topic can stay around a while for additional incoming publish or subscribers but go away if not used.

johanandren added a commit to johanandren/akka that referenced this issue Dec 15, 2023
johanandren added a commit to johanandren/akka that referenced this issue Dec 15, 2023
@johanandren johanandren self-assigned this Dec 15, 2023
johanandren added a commit to johanandren/akka that referenced this issue Dec 15, 2023
johanandren added a commit to johanandren/akka that referenced this issue Dec 19, 2023
johanandren added a commit to johanandren/akka that referenced this issue Dec 19, 2023
johanandren added a commit that referenced this issue Dec 20, 2023
johanandren added a commit to johanandren/akka that referenced this issue Dec 20, 2023
He-Pin pushed a commit to He-Pin/akka that referenced this issue Jan 7, 2024
@johanandren
Copy link
Member Author

Waiting for review in #32262

johanandren added a commit that referenced this issue Jan 8, 2024
@johanandren johanandren added this to the 2.9.2 milestone Jan 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted t:typed
Projects
None yet
Development

No branches or pull requests

2 participants