[jira] [Comment Edited] (CASSANDRA-10993) Make read and write requests paths fully non-blocking, eliminate related stages

["Tyler Hobbs (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-10993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15362811#comment-15362811 ] 

Tyler Hobbs edited comment on CASSANDRA-10993 at 7/5/16 5:24 PM:
-----------------------------------------------------------------

I talked with Jake and Aleksey about what to focus on next with this.  We'd like to get a better picture of how the performance of this approach compares to trunk.  Additionally, we'd like to see how this compares to the RxJava approach on CASSANDRA-10528 under "ideal" conditions (RF=1 reads directly from a memtable).

Aleksey and I think the integration with the Netty event loop is pretty crucial for performance, so I'm going to try to wrap up part of that before we benchmark.  It happens to be a lot easier to integrate with the Netty NIO event loop rather than the epoll event loop, so I'm going to focus on NIO and limit the benchmarks to that.

Once that's complete, we can get some better benchmark numbers around writes on 10993 vs trunk, and reads on 10993 vs trunk vs RxJava.  These should give us a better idea about how to proceed.


was (Author: thobbs):
I talked with Jake an Aleksey about what to focus on next with this.  We'd like to get a better picture of how the performance of this approach compares to trunk.  Additionally, we'd like to see how this compares to the RxJava approach on CASSANDRA-10528 under "ideal" conditions (RF=1 reads directly from a memtable).

Aleksey and I think the integration with the Netty event loop is pretty crucial for performance, so I'm going to try to wrap up part of that before we benchmark.  It happens to be a lot easier to integrate with the Netty NIO event loop rather than the epoll event loop, so I'm going to focus on NIO and limit the benchmarks to that.

Once that's complete, we can get some better benchmark numbers around writes on 10993 vs trunk, and reads on 10993 vs trunk vs RxJava.  These should give us a better idea about how to proceed.

> 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
>
>
> 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)