HDDS-10154. isKeyPresentInTable should use the constructor with prefix

[kerneltime]

What changes were proposed in this pull request?

isKeyPresentInTable should use the constructor with prefix.

The table iterator implemented over rocksDB can seek to the prefix if provided at the time to construction. This can avoid wasteful seekToFirst behavior that is part of the construction of the iterator.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-10154

How was this patch tested?

Existing tests

[errose28]

@kerneltime can you explain the difference in the two options? Looking at the code it seems both options end up calling RDBStoreAbstractIterator#seek0 soon after the iterator is created. Based on the RocksDB API it does not look like the underlying implementation does anything different in these two cases.

[kerneltime]

@kerneltime can you explain the difference in the two options? Looking at the code it seems both options end up calling RDBStoreAbstractIterator#seek0 soon after the iterator is created. Based on the RocksDB API it does not look like the underlying implementation does anything different in these two cases.

When the constructor is called without prefix

  RDBStoreByteArrayIterator(ManagedRocksIterator iterator,
      RDBTable table, byte[] prefix) {
    super(iterator, table,
        prefix == null ? null : Arrays.copyOf(prefix, prefix.length));
    seekToFirst();
  }

seekToFirst() does

  public final void seekToFirst() {
    if (prefix == null) {
      rocksDBIterator.get().seekToFirst();
    } else {
      seek0(prefix);
    }
    setCurrentEntry();
  }

which in turn calls

  @Override
  public void seekToFirst() {
    assert (isOwningHandle());
    seekToFirst0(nativeHandle_);
  }

[kerneltime]

@kerneltime can you explain the difference in the two options? Looking at the code it seems both options end up calling RDBStoreAbstractIterator#seek0 soon after the iterator is created. Based on the RocksDB API it does not look like the underlying implementation does anything different in these two cases.

This behavior was first fixed for https://issues.apache.org/jira/browse/HDDS-8289. There needs to be a clean up of TableIterators to behave the same way when in memory vs via RocksDB. My initial attempt to clean up this code did not go as cleanly as this works only when the table type is RocksDB. I am continuing to investigate how to make the behavior the same (always initialize the iterator with prefix when prefix is available) independent of the backing table.

[duongkame]

Thanks for the patch @kerneltime . LGTM.

[adoroszlai]

Thanks @kerneltime for the patch, @duongkame, @errose28 for the review.