Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 1 Jul 2013 20:26:20 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12655455.1372469443278.193572.1372710380488@arcas>
In-Reply-To: <JIRA.12655455.1372469443278@arcas>
References: <JIRA.12655455.1372469443278@arcas>
Subject: [jira] [Assigned] (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.atla=
ssian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sylvain Lebresne reassigned CASSANDRA-5714:
-------------------------------------------

    Assignee: Sylvain Lebresne
   =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
>
> 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