[ https://issues.apache.org/jira/browse/CASSANDRA-10993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15428042#comment-15428042 ]
Jason Brown commented on CASSANDRA-10993: ----------------------------------------- bq. Isn't this a good example of a case where we can start with an off the shelf API (Rx, or Reactor) and optimize later? I think this is a good point of departure, and I agree with [~jbellis]'s comments . TBH, I'm a bit worried about the time investment to actually build the custom solution (note: this is not a jab at anyone's abilities or anything, but recognizing the complexity vs. available labor vs. time to ship). 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, I think we should start with the off-the-shelf library to deliver value to our users sooner. > 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)