jayyyyqwq opened a new pull request, #29707:
URL: https://github.com/apache/flink/pull/29707
## What is the purpose of the change
`ForStSyncMapState` can crash the JVM while iterating a map.
The map iterator reads up to 128 entries at a time. To read the next batch
it seeks to the last entry it returned and, if that entry was not removed
through the iterator, calls `next()` to skip it. `MapState.remove()` does not
update the iterator's cached `deleted` flag. If the last returned entry is
removed that way, and nothing is left after it in the column family, the seek
ends past the end and `next()` is called on an invalid iterator. In my run the
test JVM died in native code.
`RocksDBMapState` already checks `iterator.isValid()` before this `next()`
(`RocksDBMapState.java:709`). `ForStSyncMapState` does not
(`ForStSyncMapState.java:671` before this change).
## Brief change log
- Check `iterator.isValid()` before skipping the resume entry in
`ForStSyncMapState`'s cache reload, and add a short comment on why.
- Add two tests to `ForStStateBackendTest`.
## Verifying this change
This change added tests and can be verified as follows:
- `testMapStateIteratorReloadWhenResumeEntryAndLastEntryRemoved` puts 129
entries, reads the first 128, removes entries 127 and 128 with
`MapState.remove()` and calls `hasNext()`. Without the change the test JVM
crashes in `RocksIterator.next` called from
`ForStSyncMapState$RocksDBMapIterator.loadCache()`. With the change it passes.
- `testMapStateIteratorReloadWhenOnlyLastEntryRemoved` is the same but
only removes entry 128, so the seek still finds entry 127. It passes with and
without the change.
I ran these on Windows with JDK 21. ForSt cannot open a database there
without path changes, so I used local-only workarounds that are not part of
this PR. I did not run on Linux.
`ForStStateBackendTest`: 150 tests run, 0 failures, 1 error before the
change. After the change, 154 run, 0 failures, 1 error. The 4 extra runs are
the new tests. The one error is the same on both: the class temp directory
cannot be deleted on Windows because a `db\LOCK` file is held. `spotless:check`
and `checkstyle:check` pass on `flink-statebackend-forst`. I did not run `mvn
clean verify`, the rest of the module's tests, or any other module.
## Does this pull request potentially affect one of the following parts:
- Dependencies (does it add or upgrade a dependency): no
- The public API, i.e., is any changed class annotated with
`@Public(Evolving)`: no
- The serializers: no
- The runtime per-record code paths (performance sensitive): no
- Anything that affects deployment or recovery: JobManager (and its
components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
- The S3 file system connector: no
## Documentation
- Does this pull request introduce a new feature? no
- If yes, how is the feature documented? not applicable
---
##### Was generative AI tooling used to co-author this PR?
<!--
If generative AI tooling has been used in the process of authoring this PR,
please
change the checkbox below to `[X]` and replace the placeholder in the
"Generated-by"
line with the tool name and version. Otherwise remove the "Generated-by"
line.
See the ASF Generative Tooling Guidance for details:
https://www.apache.org/legal/generative-tooling.html
You are responsible for the quality and correctness of every change in this
PR
regardless of the tooling used. Low-effort AI-generated PRs will be closed.
See
AGENTS.md for the full guidance.
-->
- [ ] Yes (please specify the tool below)
Generated-by: [Tool Name and Version]
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
