cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10993) Make read and write requests paths fully non-blocking, eliminate related stages
Date Wed, 17 Aug 2016 17:11:21 GMT

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

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

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

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

Mime
View raw message