KAFKA-9929: Support reverse iterator on KeyValueStore

[jeqo]

Implements KIP-617 on KeyValueStore.

Testing strategy: extend existing tests to validate reverse operations are supported.

Committer Checklist (excluded from commit message)

• Verify design and implementation
• Verify test coverage and CI build status
• Verify documentation (including upgrade notes)

[jeqo]

cc @ableegoldman

This PR is ready for review, covering related feedback from #8976

[ableegoldman]

Thanks for splitting this up! Mostly minor comments on the KVStore PR, some general notes about the Streams style conventions:

1. always use braces for if/else/etc and put each condition on its own line
2. We're trying to move away from using @Test(expected) in the tests in favor of assertThrows. A lot of the tests haven't been migrated over yet, but just a heads up

[ableegoldman]

Seems a bit tricky to say that to is the variable where iteration starts from 😉 But I can see it both ways, so being clear in the javadocs is good enough for me

[ableegoldman]

nit: RawToKey --> RawLastKey

[ableegoldman]

Also it should be from for the reverse case, right?

[jeqo]

right. I've moved this into each condition to set a correct exception message.

[jeqo]

@ableegoldman this should be ready for another review :)

[ableegoldman]

Did a quick survey of everywhere that implements range() and all() to see if there might be anywhere else we need to add reverseRange and reverseAll. These guys seem to be missing their reverse counterparts:

• KeyValueStoreReadWriteDecorator
• KeyValueToTimestampedKeyValueByteStoreAdapter
• Segment (this one is not strictly necessary until the WindowStore PR though)

The fact that you've had to add these to about 25 different classes already really highlights the mess of the store hierarchy 😬

[ableegoldman]

We need to branch on reverse here too, right?

[ableegoldman]

Kind of unrelated, but WDYT about renaming RocksDBDualCFIterator to RocksDBDualCFAllIterator or something on the side? I feel like these iterators could be cleaned up a bit in general to be more understandable -- for example, it's weird that we do the iterator#seek-ing in the actual all() method but for range queries we do the seeking inside the iterator constructor.
Just thinking out loud though, we can do some followup refactoring once this is merged

[jeqo]

Agree. I will continue the current approoach and create an issue to follow up this.

[jeqo]

https://issues.apache.org/jira/browse/KAFKA-10409

[ableegoldman]

I think we should add some tests to RocksDBTimestampedStoreTest. I thought it would extend AbstractKeyValueStoreTest and thus benefit from everything you added here, but doesn't seem to be the case :/
Personally I found the RocksDBDualCFIterator logic a bit difficult to follow even before the reverse iteration, so it would be nice to have some tests specifically covering reverse iterators over multi-column-family timestamped stores

[jeqo]

Just realized that, I also thought that path was tested. Good catch!

[jeqo]

@ableegoldman I have extended RocksDBTimestampedStoreTest to use reverseAll and reverseRange as part of the current tests.
Unfortunately, AbstractKeyValueStoreTest tests do not fit with the creation path of Timestamped stores as pre inserted data is required.
Will add this to the same JIRA ticket to consider when refactoring iterators and tests.

[ableegoldman]

Ah, that makes sense I guess. Looks like the new additions to RocksDBTimestampedStoreTest cover the cross-column family code path so that's good enough for now

[ableegoldman]

Thanks for the PR! Things LGTM now, I'll ping a committer to give this another pass and get it merged.

Let me know when the WindowStore PR is ready and I'll start reviewing the next one 😄

[vvcephei]

Thanks for the PR, @jeqo ! I made a partial pass today. It looks really good overall.

A high-level comment: in several places in this code, we have a internal boolean flag to represent the direction. It seems odd that in these places, true = reverse. It seems like the "natural" iteration order is forward, so we should have blocks like if (forward) /*forward logic*/ else /*reverse logic*/. But what we have here is if (not reverse) /*forward logic*/ else /*reverse logic*/. It's not exactly hard to understand, but still it seems to be creating unnecessary hoops for people to jump through when they are reading the code.

[vvcephei]

This warning seems to miss the most likely scenario, that the user just passed the arguments in the wrong order.

[vvcephei]

Hey @jeqo , I've completed my review. It looks good to me! Thanks so much for the KIP and PR.

Please let me know what you want to do about my prior comments, if anything :)

[vvcephei]

clever!

[jeqo]

@vvcephei thanks for your feedback! Inverting flag actually make things more readable. Changing to forward and if (forward) {} else {}.

[vvcephei]

Thanks @jeqo !

[vvcephei]

It looks like java 14 only failed while attempting to download some docs from Oracle, and java 8 failed on this unrelated test: org.apache.kafka.clients.admin.KafkaAdminClientTest.testMetadataRetries