Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
KAFKA-15443: Upgrade RocksDB to 9.7.3 #18275
KAFKA-15443: Upgrade RocksDB to 9.7.3 #18275
Changes from all commits
6ae30ed
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
It's too bad that RockDB does not mark methods as deprecated but just removes stuff.
This was always an issue for us (even if we have to admit, that we are upgrade from a quite old version...). I guess we just need to bite the bullet and make this breaking change... Seem we need to start tracking RocksDB changes more closely and frequently and do KIPs early on to prepare for breaking changes. (What basically implies, that we can upgrade RocksDB only in major release if there are breaking changes...)
Or we change our "policy" for RocksDB compatibility and document it properly, reserving the right to break compatibility via RocksDB version bumps also in minor release.
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.
Yeah this drives me crazy. Personally I think it's ok to bite the bullet on this one but let's definitely come up with a strategy for this going forward. I'd say a good compromise is to meet in the middle and do both, that is, publish an official policy for RocksDB APIs which says there is no guarantee of the usual one-year deprecation & only major version removal, and any deprecations are best-effort. I'm less worried about the deprecations and more about restricting our ability to upgrade rocksdb to only major releases.
At the same time, I think we can and should do better. I like the idea of looking ahead at each new RocksDB release to mark any changed or removed APIs exposed to our users so we can deprecate them ASAP. We can hash out the details of how often and how to share this responsibility later (for example maybe this should be one of the Streams RM responsibilities, to look for upcoming API changes in future rocks and make sure they get deprecated in that release
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.
If this was removed, too, can you add it to the PR description.
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.
@mjsax thanks for feedback. I wanted to confirm setLogger() method. Parameter inside setLogger() has changed to LoggerInterface. I've made corrections and put method back in that java class.
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.
It is fine to change it like you did. If users use a logger class that is derived from
Logger
they have to modify it in any case becauseLogger
now implements interfaceLoggerInterface
. Thus, the change of the method will most likely not directly affect users on a source level. It will affect them on binary level, though, but that is the trade-off here.