Skip to content
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

Single node META FATE data #5127

Merged
merged 4 commits into from
Dec 16, 2024
Merged

Conversation

kevinrr888
Copy link
Member

@kevinrr888 kevinrr888 commented Dec 2, 2024

closes #4905

  • Moved all the fate data for a single META transaction into a single ZK node
    • Pushed all the data into NodeValue (renamed to FateData)
    • Previously, FateData stored TStatus, FateReservation, and FateKey. Now additionally stores the REPO stack and TxInfo.
  • Status enforcement added to MetaFateStore (previously only possible for UserFateStore).
  • Moved testFateInitialConfigCorrectness() from UserFateStoreIT to UserFateIT
  • Renamed UserFateStoreIT to UserFateStatusEnforcementIT (now extends a new class FateStatusEnforcementIT)
    • Now only tests status enforcement (previously status enforcement + testFateInitialConfigCorrectness())
  • Created MetaFateStatusEnforcementIT (extends FateStatusEnforcementIT)
    • Tests that the new status enforcement in MetaFateStore works
  • Created FateStoreUtil, moving the createFateTable() util here, created MetaFateZKSetup inner class here (the counterpart to createFateTable() for UserFateStore but sets up ZooKeeper for use in MetaFateStore)
  • Deleted UserFateStoreITs (now UserFateStatusEnforcementIT) method injectStatus replacing with the existing setStatus which does the same thing
  • Ensured sunny day and all FATE tests still pass with these changes

I did not end up using JSON for the fate data. I was not sure what the benefit of this would be since the data needs to be stored in ZK as a byte array anyways and it seemed simpler to me to just keep the same serialization/deserialization strategy for the fate data. Maybe this could be changed to JSON in a follow on if there would be a benefit of using JSON over the current strategy.

- Moved all the fate data for a `META` transaction into a single ZK node
	- Pushed all the data into `NodeValue` (renamed to `FateData`)
	- Previously, `FateData` stored `TStatus`, `FateReservation`, and `FateKey`. Now additionally stores the `REPO` stack and `TxInfo`.
- Status enforcement added to `MetaFateStore` (previously only possible for `UserFateStore`).
- Moved `testFateInitialConfigCorrectness()` from `UserFateStoreIT` to `UserFateIT`
- Renamed `UserFateStoreIT` to `UserFateStatusEnforcementIT` (now extends a new class `FateStatusEnforcementIT`)
	- Now only tests status enforcement (previously status enforcement + `testFateInitialConfigCorrectness()`)
- Created `MetaFateStatusEnforcementIT` (extends `FateStatusEnforcementIT`)
	- Tests that the new status enforcement in `MetaFateStore` works
- Created `FateStoreUtil`, moving the `createFateTable()` util here, created MetaFateZKSetup inner class here (the counterpart to `createFateTable()` for `UserFateStore` but sets up ZooKeeper for use in `MetaFateStore`)
- Deleted `UserFateStoreIT`s (now `UserFateStatusEnforcementIT`) method `injectStatus` replacing with the existing `setStatus` which does the same thing
@kevinrr888 kevinrr888 self-assigned this Dec 2, 2024
@kevinrr888 kevinrr888 added this to the 4.0.0 milestone Dec 2, 2024
Copy link
Contributor

@keith-turner keith-turner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes look good. The test cleanup and reorg is nice. The only possible problem I saw was the repo ser/deser. Wondering if the ! char could occur in serialized data. Would be nice to avoid that.

- Got rid of END_REPO_DATA marker, replacing with simply writing the number of repos to read
- Avoid AtomicBoolean in `MetaFateStore.FateTxStoreImpl.push(repo)` by changing StackOverflowException to instead be a RuntimeException (previously Exception)
- Deleted unnecessary preexisting catch and immediate re-throw of a StackOverflowException in `MetaFateStore.FateTxStoreImpl.push(repo)`
- Cleaned up and refactored `MetaFateStore` methods which mutate existing FateData; now reuse same pattern across these methods: all call new method `MetaFateStore.mutate()`
@kevinrr888
Copy link
Member Author

Addressed in 29edaa2:

  • Got rid of END_REPO_DATA marker, replacing with simply writing the number of repos to read
  • Avoid AtomicBoolean in MetaFateStore.FateTxStoreImpl.push(repo) by changing StackOverflowException to instead be a RuntimeException (previously Exception)
  • Deleted unnecessary preexisting catch and immediate re-throw of a StackOverflowException in MetaFateStore.FateTxStoreImpl.push(repo)
  • Cleaned up and refactored MetaFateStore methods which mutate existing FateData; now reuse same pattern across these methods: all call new method MetaFateStore.mutate()

@kevinrr888
Copy link
Member Author

Resolved the conflicts from the recent seed transaction speedup. Thankfully, those changes were mostly for UserFateStore and these are for MetaFateStore, so conflicts were very easy

@kevinrr888 kevinrr888 merged commit 2abf5b1 into apache:main Dec 16, 2024
8 checks passed
@kevinrr888 kevinrr888 deleted the 4.0-feature-4905 branch December 16, 2024 16:06
asfgit pushed a commit that referenced this pull request Dec 16, 2024
* Fix unused import introduced in #5127
* Remove dead code for `--fixFiles` in Admin checks left by #4957
* Fix unclosed resource warning introduced in #5148
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Single ZK node fate data
2 participants