Repository navigation
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3299 +/- ##
============================================
+ Coverage 57.27% 58.05% +0.78%
+ Complexity 6577 3 -6574
============================================
Files 776 508 -268
Lines 68881 49257 -19624
Branches 9431 7320 -2111
============================================
- Hits 39449 28595 -10854
+ Misses 25804 17949 -7855
+ Partials 3628 2713 -915
☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
a440bdc to
6a068b9
Compare
Clear OLAP data without dropping its column family. Route the clear to the owning database under the store lock. Discard only the clearing threads pending batch. Cover handle identity, other tables, reuse and reopen.
6a068b9 to
34cc360
Compare
bitflicker64
left a comment
There was a problem hiding this comment.
Blocking: no. Summary: The Topling branch clears the selected OLAP table through the existing RocksDBSessions.clearTables path under the store write lock, with balanced useSession/close and the standard drop/create path unchanged; no correctness defect found in the Java change, two small test-coverage notes inline. Real Topling JNI shutdown behaviour was not exercised by this review or by CI. Evidence: read the full diff at 34cc360 against merge base 87a06a9 plus RocksDBStore, RocksDBSessions.clearTables, BackendSessionPool, RocksDBStdSessions.StdSession and the callers (GraphTransaction.clearOlapPk, OlapPropertyKeyClearJob); RocksDBSstStore does not inherit clearOlapTable so the SST backend is unaffected; CI job build-server / server_memory (Java 17) ran UnitTestSuite at this head: 999 tests, 0 failures, 0 errors.
Compare each recreated handle with the previous clear. Pin pending writes committed after another worker clears. Document concurrent writes after OLAP property clear.
Retry transient cleanup disconnects after explicit stop. Keep credential and target PID checks before stopping an agent. Reproduce the race with a one-shot fault around the native CLI. Cover OLAP clear rollback and session leases after failed commits.
bitflicker64
left a comment
There was a problem hiding this comment.
Blocking: no. Score: 9/10. Summary: The Topling branch of clearOlapTable clears only the selected OLAP table through RocksDBSessions.clearTables under the store write lock, resets the clearing thread's batch and keeps its CF handle, while the standard path keeps drop/create; the earlier handle-refresh, second-thread and AtomicReference fixture notes are addressed, and the Arthas probe retry keeps the credential and PID checks.
Purpose of the PR
Topling's standalone OLAP property clear still drops and recreates the same column family. The previously reported real-JNI reproduction completes the clear task, then aborts during normal shutdown. This change clears the selected table while retaining its CF handle.
Addresses the OLAP clear/close item already tracked in #3242 and the original review. The release checklist stays open. Existing Topling and recovery PRs were checked; the merged runtime integration and snapshot-recovery fix #3293 do not cover this clear path.
Main Changes
AtomicReferenceowner introduced by merged fix(rocksdb): make snapshot restore retryable #3293.Verifying these changes
RocksDBSessionsTest: 30 tests pass on Java 17, with no failures/errors/skips. Coverage includes retained handle identity, recreation on each repeated standard clear, pending writes outside the stored range and in an empty table, independent OLAP routing, other-table preservation, reuse and close/reopen reads. A failed-commit test verifies rollback, retained handles, balanced session references and successful retry. A second-thread test verifies that a batch staged before clear can repopulate the table when committed afterward.PropertyKeyCoreTest: 24 tests pass on Java 17 with the RocksDB backend, including OLAP clear/remove integration coverage.git diff --checkpass.The full Linux Arthas CLI suite, including the shutdown-race regression, passed on this head in CI run 41295617424. Other jobs in that run are still in progress. The local macOS run stops at the IPv6 closed-port check: the bundled client returns exit 100 without the connection-refused diagnostic. The remaining macOS native CLI scenarios pass in a local copy excluding that explicit IPv6 bind case; this does not establish a complete native CLI pass.
These tests run the Topling Java branch with the real standard RocksDB JNI. The same handle-preservation regression fails against the original master adapter. Actual Topling JNI and its reported shutdown abort were not rerun on this macOS arm64 host; current-head Linux native qualification remains necessary.
Does this PR potentially affect the following parts?
Documentation Status
Doc - TODODoc - Done:docs/storage-lifecycle.mddocuments OLAP clear, handle retention and pending-write handling, including later commits from concurrent writers and the difference from graph truncate.Doc - No NeedConceptual overview
Topling OLAP clear 保留 CF handle,标准 RocksDB 仍走 drop/create,实际 Topling JNI 验收仍需完成。
Conceptual illustration; not test or release-acceptance evidence.
English conceptual overview
Concept illustration of the Topling OLAP clear path: reset the clearing thread's pending batch, clear the selected table in its owning database, and retain the CF handle. Standard RocksDB retains drop/create; actual Topling JNI qualification remains required.