-
Notifications
You must be signed in to change notification settings - Fork 3.6k
feat: eager "pre-resolution" of shard homes #32881
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
base: main
Are you sure you want to change the base?
Changes from all commits
55e1509
1f3dd5b
335cad8
49ce6bd
4e2c011
151c79e
3fc3ab7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -649,6 +649,16 @@ class ClusterSharding(system: ExtendedActorSystem) extends Extension { | |
| } | ||
| } | ||
|
|
||
| /** | ||
| * Direct the [[ShardRegion]] actor responsible for the named entity type to resolve the location | ||
| * of the given shard and cache it. If the `ShardRegion` already knows the location, it will not do anything, | ||
| * otherwise it will request the home of the shard, which may result in the shard being allocated on | ||
| * some node in the cluster. No message will be sent to any entity within the shard. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would it even be possible to automate this (if feature is enabled in config)? For remember entities we have already unallocatedShards in the Coordinator State. Could we make use of that and automatically pre-allocate shards from the coordinator? Once a shard has been in use, it will always be allocated again as soon as possible (best effort). |
||
| */ | ||
| def preResolveShard(typeName: String, shard: ShardRegion.ShardId): Unit = { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For the classic api we should follow the existing convention to have this as public message that is sent to the shardRegion instead of via this additional method. See for example |
||
| shardRegion(typeName) ! ShardRegion.ResolveShard(shard) | ||
| } | ||
|
|
||
| /** | ||
| * Retrieve the actor reference of the [[ShardRegion]] actor that will act as a proxy to the | ||
| * named entity type running in another data center. A proxy within the same data center can be accessed | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we should follow the existing convention here too, that it's actor messages. We have that for the ClusterShardingQuery and ShardCommand/Passivate. I think we can expand the ShardCommand with this PreResolveShard message.