Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 17 Aug 2016 17:11:21 +0000 (UTC)
From: "Tyler Hobbs (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12929059.1452475897000.333415.1471453881091@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: Wed, 17 Aug 2016 17:11:24 -0000


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

Tyler Hobbs commented on CASSANDRA-10993:
-----------------------------------------

bq. I don=E2=80=99t mind the API itself (which we=E2=80=99ll have to modify=
, to make it explicitly token/core-aware, with heavy modifications for sche=
duling as well)

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.

bq. In other words, C* committers and devs should pick the style, and we=E2=
=80=99ll go with it. But, please, not with the library itself.

Can you clarify what you mean?  Are you saying that you're okay with the Rx=
-style API, but would prefer to have our own version of it for more control=
?

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