[
https://issues.apache.org/jira/browse/CASSANDRA-10993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15437021#comment-15437021
]
Aleksey Yeschenko commented on CASSANDRA-10993:
-----------------------------------------------
I'd like to remind everybody here that this is not a standalone ticket, it's
just a step towards TPC transition. So the solution should be chosen with that
in mind. There is more to TPC than just making read and write paths
asynchronous.
We will have cores sharded by the token range at some point. The API of the
library, custom or off-the-shelf, should allow for scheduling the futures for
execution on the appropriate core. We'll also need proper asynchronous file I/O
eventually.
What we *need* is an equivalent of (narrower scoped) seestar/windmill. The
latter is currently unavailable for legal reasons, but the library was pretty
small, and didn't take that long to create. So given what we *need* as opposed
to nice to have, I reject the expensive investment argument. It will not take
long to create just what we need, and windmill is the precedent.
bq. It's fairly easy to write schedulers for Rx, at least (Jake wrote a couple
in his branch), so I don't think this part will be particularly bad.
Well, given that this is the core part that we need, we better show, first,
that it can indeed be done. Can't just hand-wave it away.
bq. (and I think Tyler's tests show it's decent enough to be competitive with
state machine, at least)
Performance comparison at this point is relatively meaningless, given that we
aren't to see significant benefits until later in the transition. The only
number we care about is POC vs. trunk, and success criteria at this stage is
lack of performance regression (or presence of a minimal one), so I don't see
how this is relevant.
bq. If we can hit a large percentage of our target performance goal with using
an off-the-shelf library, and swapping to the custom solution could be
reasonable after that
See above.
> Make read and write requests paths fully non-blocking, eliminate related
> stages
> -------------------------------------------------------------------------------
>
> Key: CASSANDRA-10993
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10993
> Project: Cassandra
> Issue Type: Sub-task
> Components: Coordination, Local Write-Read Paths
> Reporter: Aleksey Yeschenko
> Assignee: Tyler Hobbs
> Fix For: 3.x
>
> Attachments: 10993-reads-no-evloop-integration-six-node-stress.svg,
> tpc-benchmarks-2.txt, tpc-benchmarks.txt
>
>
> Building on work done by [~tjake] (CASSANDRA-10528), [~slebresne]
> (CASSANDRA-5239), and others, convert read and write request paths to be
> fully non-blocking, to enable the eventual transition from SEDA to TPC
> (CASSANDRA-10989)
> Eliminate {{MUTATION}}, {{COUNTER_MUTATION}}, {{VIEW_MUTATION}}, {{READ}},
> and {{READ_REPAIR}} stages, move read and write execution directly to Netty
> context.
> For lack of decent async I/O options on Linux, we’ll still have to retain an
> extra thread pool for serving read requests for data not residing in our page
> cache (CASSANDRA-5863), however.
> Implementation-wise, we only have two options available to us: explicit FSMs
> and chained futures. Fibers would be the third, and easiest option, but
> aren’t feasible in Java without resorting to direct bytecode manipulation
> (ourselves or using [quasar|https://github.com/puniverse/quasar]).
> I have seen 4 implementations bases on chained futures/promises now - three
> in Java and one in C++ - and I’m not convinced that it’s the optimal (or
> sane) choice for representing our complex logic - think 2i quorum read
> requests with timeouts at all levels, read repair (blocking and
> non-blocking), and speculative retries in the mix, {{SERIAL}} reads and
> writes.
> I’m currently leaning towards an implementation based on explicit FSMs, and
> intend to provide a prototype - soonish - for comparison with
> {{CompletableFuture}}-like variants.
> Either way the transition is a relatively boring straightforward refactoring.
> There are, however, some extension points on both write and read paths that
> we do not control:
> - authorisation implementations will have to be non-blocking. We have control
> over built-in ones, but for any custom implementation we will have to execute
> them in a separate thread pool
> - 2i hooks on the write path will need to be non-blocking
> - any trigger implementations will not be allowed to block
> - UDFs and UDAs
> We are further limited by API compatibility restrictions in the 3.x line,
> forbidding us to alter, or add any non-{{default}} interface methods to those
> extension points, so these pose a problem.
> Depending on logistics, expecting to get this done in time for 3.4 or 3.6
> feature release.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
