cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9975) Flatten Iterator call hierarchy with a shared Transformer
Date Sun, 13 Sep 2015 13:23:46 GMT

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

Benedict commented on CASSANDRA-9975:
-------------------------------------

On writing the follow up, CASSANDRA-9976, it became apparent it was easier and cleaner to
do both at once, since they ultimately share quite a bit of functionality and approach. This
is now available [here|https://github.com/belliottsmith/cassandra/tree/9975]. 

This version also goes a step further to completely eliminate the wrapping partition iterators,
and all but a handful of wrapping row iterators (the remainder of which can be eliminated
following CASSANDRA-9986). This is achieved by supporting concatenation / short read protection
via a transformation function that "refils" the contents of an iterator with one or more new
iterators. i.e.m once the input we're transforming is exhausted, we ask for a new one, which
is swapped in, and the function stacks updated as necessary. This all but eliminates the jumping
around of control flow for the outer execution of a query, although the inner execution (memtable,
sstable) still has some cleaning up to be done to make it easy to debug.

> Flatten Iterator call hierarchy with a shared Transformer
> ---------------------------------------------------------
>
>                 Key: CASSANDRA-9975
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9975
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Benedict
>            Assignee: Benedict
>             Fix For: 3.0.x
>
>
> Stepping through a read response is made exceedingly difficult by the sheer depth of
the call hierarchy, and how rapidly your context jumps around. This ticket intend to partially
address that, by flattening one of the main causes of this: iterator transformations.
> I have a patch that attempts to mitigate (but not entirely eliminate) this, through the
introduction of a {{RowTransformer}} class that all transformations are applied through. If
a transformation has already been applied, the {{RowTransformer}} class does not wrap a new
iterator, but instead returns a new {{RowTransformer}} that wraps the original underlying
(untransformed) iterator and both transformations. This can accumulate an arbitrary number
of transformations and, quite importantly, can apply the filtration step {{Unfiltered ->
Row}}  in the same instance as well. The intention being that a majority of control flow happens
inside this {{RowTransformer}}, so there is far less context jumping to cope with.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message