Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 1 Jul 2013 23:10:21 +0000 (UTC)
From: =?utf-8?Q?Micha=C3=ABl_Figui=C3=A8re_=28JIRA=29?= <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12655455.1372469443278.195139.1372720221836@arcas>
In-Reply-To: <JIRA.12655455.1372469443278@arcas>
References: <JIRA.12655455.1372469443278@arcas>
Subject: [jira] [Commented] (CASSANDRA-5714) Allow coordinator failover for
 cursors
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-5714?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
13697306#comment-13697306 ]=20

Micha=C3=ABl Figui=C3=A8re commented on CASSANDRA-5714:
---------------------------------------------

I like this solution. Some extra advantages that I can see in detaching the=
 paging state from the connection:
* The previous solution could lead to an over consumption of StreamIds as t=
he driver cannot reuse them until the paging is complete. In some use cases=
 that would have force the user to provision a large amount of connections =
just to avoid slowdowns due to StreamIds exhaustion.
* This design offer many API options on the client side: implicit automatic=
 paging, explicit one with sync/async calls (e.g. to allow multiple paging =
in parallel from a single client thread), copying the paging state to a dif=
ferent process,...
               =20
> Allow coordinator failover for cursors
> --------------------------------------
>
>                 Key: CASSANDRA-5714
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5714
>             Project: Cassandra
>          Issue Type: Improvement
>    Affects Versions: 1.2.0 beta 1
>            Reporter: Micha=C3=ABl Figui=C3=A8re
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 2.0 beta 1
>
>
> With CASSANDRA-4415 if a coordinator fails or gets slow, causing the {{NE=
XT}} request to timeout, the client application won't be able to complete i=
ts browsing of the result. That implies that most of the time when the deve=
loper will rely on cursors he will have to write some logic to handle a ret=
ry request for results starting where the iteration failed. This will quick=
ly become painful.
> Ideally the driver should handle this failover by itself by transparently=
 issuing this retry query when {{NEXT}} fail, but as the driver doesn't und=
erstand CQL queries, the only thing it's aware of is the number of rows alr=
eady read. Therefore we should allow an optional parameter {{<initial_row_n=
umber>}} in {{QUERY}} and {{EXECUTE}} messages that would allow a kind of s=
tateless failover of cursors.
> With such an option, developers wouldn't have to write any failover/retry=
 logic on failure as they would know that everything has already been tried=
 by the driver.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira