-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Fix FollowingEngineTests#testOptimizeMultipleVersions #75583
Conversation
In certain concurrent indexing scenarios where there are deletes executed and then a new indexing operation, the following engine considers those as updates breaking one of the assumed invariants. Closes elastic#72527
Pinging @elastic/es-distributed (Team:Distributed) |
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 left a few comments, mainly on the test.
.../plugin/ccr/src/test/java/org/elasticsearch/xpack/ccr/index/engine/FollowingEngineTests.java
Outdated
Show resolved
Hide resolved
.../plugin/ccr/src/test/java/org/elasticsearch/xpack/ccr/index/engine/FollowingEngineTests.java
Outdated
Show resolved
Hide resolved
x-pack/plugin/ccr/src/main/java/org/elasticsearch/xpack/ccr/index/engine/FollowingEngine.java
Show resolved
Hide resolved
.../plugin/ccr/src/test/java/org/elasticsearch/xpack/ccr/index/engine/FollowingEngineTests.java
Outdated
Show resolved
Hide resolved
Sorry, I didn't have the chance to look into this until now. I've added a synchronization point between the test threads that should make the issue easier to reproduce, before it took > 1000 runs to reproduce. |
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.
@@ -118,14 +118,27 @@ protected long generateSeqNoForOperationOnPrimary(final Operation operation) { | |||
} | |||
|
|||
@Override | |||
protected void advanceMaxSeqNoOfUpdatesOrDeletesOnPrimary(long seqNo) { | |||
protected void advanceMaxSeqNoOfDeleteOnPrimary(long seqNo) { |
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 think we should keep this in plural, i.e., advanceMaxSeqNoOfDeletesOnPrimary
} | ||
|
||
@Override | ||
protected void advanceMaxSeqNoOfUpdateOnPrimary(long seqNo) { |
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.
Also plural here for consistency.
// maxSeqNoOfUpdatesOrDeletes, since in this engine (effectively it is a replica) we don't check if the previous version | ||
// was a delete and it's possible to consider it as an update, advancing the max sequence number over the leader | ||
// maxSeqNoOfUpdatesOrDeletes. | ||
// The goal of this marker it's just an optimization and it won't affect the correctness or durability of the indexed documents. |
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.
A wrong number could lead to incorrect behavior so I suggest to rephrase this to something like:
// We conservatively advance the seqno in this case, accepting a minor performance hit in this edge case.
@elasticmachine update branch |
In certain concurrent indexing scenarios where there are deletes executed and then a new indexing operation, the following engine considers those as updates breaking one of the assumed invariants. Closes elastic#72527
💚 Backport successful
|
In certain concurrent indexing scenarios where there are deletes
executed and then a new indexing operation, the following engine
considers those as updates breaking one of the assumed invariants.
Closes #72527