Enable building JAR with support for parallel IO #13510
Open
+18
−4
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.
This change set intends to introduce the minimal set of modifications required to enable building the Java bindings with coroutine and
io_uring
support simply by runningTo achieve this without a breaking change, Folly and it's dependencies are linked in statically. The drawback of this is a slight increase in the size of the resulting library.
The purpose of this change is to allow users of the Java bindings to benefit from the capability of the
MultiGet
implementation to issue IO requests for multiple data blocks in parallel. We would like for this feature to be part of a release, and so we needROCKSDB_USE_IO_URING=1
andUSE_COROUTINES=1
, or agree to make building the JAR with coroutine support the default behavior.In case building and publishing the artifact with coroutine support by default is undesirable for some reason (maybe the dynamic dependency on liburing) would it be possible to perhaps (temporarily) release two versions of the artifact - with and without coroutine support, or find some other solution? We want to use this feature in our Java project, and we would like to avoid building and publishing our own artifacts for this reason.
Another question related to this PR I would like to ask is about the purpose of the
RocksDbIOUringEnable()
. I see that the changelog says:I assume that although
read_options.async_io
already performs the same role, there are situations where there is a need to disableio_uring
whereread_options
are not available. Since the choice to useio_uring
or not is already exposed to the user viaread_options.async_io
, is it safe for the wrappers implementation ofRocksDbIOUringEnable()
to just always returntrue
, or does it have to e.g. do some check whetherio_uring
is available on the OS (just once to avoid incurring latency), or is it expected to do something else?