Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 2 Aug 2016 21:11:21 +0000 (UTC)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12929059.1452475897000.204288.1470172281059@Atlassian.JIRA>
In-Reply-To: <JIRA.12929059.1452475897000@Atlassian.JIRA>
References: <JIRA.12929059.1452475897000@Atlassian.JIRA> <JIRA.12929059.1452475897271@arcas>
Subject: [jira] [Commented] (CASSANDRA-10993) Make read and write requests
 paths fully non-blocking, eliminate related stages
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Tue, 02 Aug 2016 21:11:23 -0000


    [ https://issues.apache.org/jira/browse/CASSANDRA-10993?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D15404795#comment-15404795 ]=20

Jonathan Ellis commented on CASSANDRA-10993:
--------------------------------------------

My gut is that we stand to realize more of a performance win from e.g. not =
needing to use threadsafe memtables than we can wring from hand-coding stat=
e machines vs reactive streams.  (Especially if the commenter on 10528 is r=
ight that Reactor outperforms RxJava already.)  So I'd be inclined to move =
forward with the approach that lets us ship v1 and start working on those n=
ext-gen optimizations faster.

Separately, do you have any intuition for why state machines does better at=
 mean latency but worse at the tail?

> Make read and write requests paths fully non-blocking, eliminate related =
stages
> -------------------------------------------------------------------------=
------
>
>                 Key: CASSANDRA-10993
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1099=
3
>             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.sv=
g, tpc-benchmarks-2.txt, tpc-benchmarks.txt
>
>
> Building on work done by [~tjake] (CASSANDRA-10528), [~slebresne] (CASSAN=
DRA-5239), and others, convert read and write request paths to be fully non=
-blocking, to enable the eventual transition from SEDA to TPC (CASSANDRA-10=
989)
> Eliminate {{MUTATION}}, {{COUNTER_MUTATION}}, {{VIEW_MUTATION}}, {{READ}}=
, and {{READ_REPAIR}} stages, move read and write execution directly to Net=
ty context.
> For lack of decent async I/O options on Linux, we=E2=80=99ll still have t=
o retain an extra thread pool for serving read requests for data not residi=
ng in our page cache (CASSANDRA-5863), however.
> Implementation-wise, we only have two options available to us: explicit F=
SMs and chained futures. Fibers would be the third, and easiest option, but=
 aren=E2=80=99t feasible in Java without resorting to direct bytecode manip=
ulation (ourselves or using [quasar|https://github.com/puniverse/quasar]).
> I have seen 4 implementations bases on chained futures/promises now - thr=
ee in Java and one in C++ - and I=E2=80=99m not convinced that it=E2=80=99s=
 the optimal (or sane) choice for representing our complex logic - think 2i=
 quorum read requests with timeouts at all levels, read repair (blocking an=
d non-blocking), and speculative retries in the mix, {{SERIAL}} reads and w=
rites.
> I=E2=80=99m 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 refactor=
ing.
> There are, however, some extension points on both write and read paths th=
at we do not control:
> - authorisation implementations will have to be non-blocking. We have con=
trol 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 th=
ose 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)