GEODE-10453 - don't lookup old key in case of REMOVE_DUE_TO_GII_TOMBSTONE_CLEANUP and CompactRangeIndex #7890
Conversation
…actRangeIndex, specify not to lookup old key, which is very expensive operation. It's actually broken and regression. All the tombstone entries are going to be NullToken and cause class cast exception for every single remove compare if looking up old key. There is no old key during initial tombstone image sync up from lead peer.
|
@JinwooHwang-SAS can you try kicking off the build for this one again? The contributor has requested this be merged and we need to be sure the tests are passing. |
|
@leonfin, Would you mind re-running the failed checks when you have a chance? I’m sorry for the inconvenience — it seems I don’t have permission to restart them myself. |
|
Restarted the checks. |
|
@JinwooHwang-SAS Just for my information, how do you restart the checks? I don't see any option for that under Checks tab on PR. It seems something wrong with docker compose setup? One of acceptance checks failed with DualServerSNIAcceptanceTest > initializationError FAILED Who can fix it? Thank you! |
|
@leonfin, I had to reopen it to trigger the checks. The errors in :geode-assembly:acceptanceTest have been addressed. We plan to merge this as soon as the rest of checks pass. Thanks. |
|
BTW original author even said in the original commit Not sure why down the code path it was missed that for GII (get initial image), the findOldKey was defaulted to true. We're already using this patched version in prod for 6+ months. |
…actRangeIndex, specify not to lookup old key, which is very expensive operation. It's actually broken and regression. All the tombstone entries are going to be NullToken and cause class cast exception for every single remove compare if looking up old key. There is no old key during initial tombstone image sync up from lead peer. (#7890) Co-authored-by: Leon Finker <[email protected]> (cherry picked from commit d834e94)
4 participants
For all changes:
[ GEODE-10453] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
[Yes ] Has your PR been rebased against the latest commit within the target branch (typically
develop)?[ Yes] Is your initial contribution a single, squashed commit?
[ Yes] Does
gradlew buildrun cleanly?[ No] Have you written or updated unit tests to verify your changes?
[ No] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?