-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Stateless real-time GET #93976
Stateless real-time GET #93976
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
Thanks for the feedback @henningandersen.
So as long as the GET request has its |
We discussed this on another channel with Henning. The disadvantage here would be that this might cause a lot of load on the indexing shards. We'd rather only contact the indexing shards for a Translog lookup. |
.../src/main/java/org/elasticsearch/action/support/single/shard/TransportSingleShardAction.java
Outdated
Show resolved
Hide resolved
This comment was marked as outdated.
This comment was marked as outdated.
server/src/main/java/org/elasticsearch/action/get/TransportGetAction.java
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/action/get/TransportShardMultiGetAction.java
Outdated
Show resolved
Hide resolved
Pinging @elastic/es-distributed (Team:Distributed) |
rest-api-spec/src/yamlRestTest/java/org/elasticsearch/test/rest/ClientYamlTestSuiteIT.java
Outdated
Show resolved
Hide resolved
@elasticmachine update branch |
1 similar comment
@elasticmachine update branch |
This is ready for review. |
f53961b
to
943a811
Compare
@elasticmachine test this please hmm... seems like an infra issue! |
943a811
to
6367839
Compare
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.
LGTM.
server/src/main/java/org/elasticsearch/action/get/TransportGetAction.java
Show resolved
Hide resolved
@@ -91,6 +110,16 @@ protected void resolveRequest(ClusterState state, InternalRequest request) { | |||
protected void asyncShardOperation(GetRequest request, ShardId shardId, ActionListener<GetResponse> listener) throws IOException { | |||
IndexService indexService = indicesService.indexServiceSafe(shardId.getIndex()); | |||
IndexShard indexShard = indexService.getShard(shardId.id()); | |||
if (indexShard.routingEntry() == null) { |
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.
Can this happen? Looks like we init it in IndexShard
constructor and then only update it to non-null values?
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.
I'm not entirely sure. I vaguely remember running into an issue in the begging when I was working on this, and adding this helped. Maybe the issue was something else. I do see that similar checks are done in a couple of other transport actions, e.g., TransportIndicesStatsAction
and DataStreamsStatsTransportAction
.
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.
Yeah, but that looks like both comes from TransportIndicesStatsAction
, which was done in 2014 and thus on a very different code base. I think we should assume this does not happen, since we assume so in other actions, for instance TransportGetFromTranslogAction
, PostWriteRefresh
and many others. Unless you know where it can happen I suggest to remove the new null check, we do not want null-checks all over for things that cannot be null.
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.
I agree!
if (shardRoutingTable.primaryShard() == null || shardRoutingTable.primaryShard().active() == false) { | ||
throw new NoShardAvailableActionException(shardId, "primary shard is not active"); | ||
} | ||
DiscoveryNode node = clusterService.state().nodes().get(shardRoutingTable.primaryShard().currentNodeId()); |
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.
Can we use the same ClusterState
instance here rather than asking for it again? That way, the null check below can turn into an assertion (assert node != null
).
@elasticmachine update branch |
@elasticmachine update branch |
The mget counterpart of #93976. Relates ES-5677
For real-time get on Stateless, we'd need to first check the indexing shard whether it has
the document in its Translog, if not we might have to wait on the search shard and then
handle the GET locally.
Relates ES-5537