[
https://issues.apache.org/jira/browse/CASSANDRA-10993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417322#comment-15417322
]
Aleksey Yeschenko commented on CASSANDRA-10993:
-----------------------------------------------
Well, RxJava and TPC are completely orthogonal.
As for performance improvements - TPC-related performance improvements will not
come any time soon.
Numbers-wise, the bar for this ticket is to try avoid any performance
regressions, or to at least minimise them.
If we can show that, we are good.
The remaining issue is the code-style. We could either go with state machines,
with completable futures/streams/flow, or
with a combination of the above. In the end, 1) they are isomorphic and 2) both
require us hand-rolling a ton of code and
3) code readability/maintainabiliiy will suffer significantly compared to our
current codebase
I’d argue that while writing more functionally is probably easier (and Tyler
finds it more palatable), reasoning about it, and debugging
it, is not a pleasant experience. For an example of this in practice, have a
look at VoltDB codebase. Then tell me if that’s in any way
acceptable.
That said, if the team wants to go that way, stylistically, I’m not going to
block it. Though, while I don’t mind the API itself (which we’ll
have to modify, to make it explicitly token/core-aware, with heavy
modifications for scheduling as well), I don’t believe that it is wise for
a project like ours to rely on an external library for the utmost core
functionality (managing execution). Our use of Netty is already pushing
it *almost* too far, but this would be unacceptable, for me. Here we need
precise control, even if that means less reuse and more NIH. One
does not outsource project’s core competency to an external library.
In other words, C* committers and devs should pick the style, and we’ll go with
it. But, please, not with the library itself.
> 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)
