cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michaël Figuière (JIRA) <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5714) Allow coordinator failover for cursors
Date Mon, 01 Jul 2013 23:10:21 GMT

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

Michaël Figuière 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 the 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 different process,...
                
> 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ël Figuière
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 2.0 beta 1
>
>
> With CASSANDRA-4415 if a coordinator fails or gets slow, causing the {{NEXT}} request
to timeout, the client application won't be able to complete its browsing of the result. That
implies that most of the time when the developer will rely on cursors he will have to write
some logic to handle a retry request for results starting where the iteration failed. This
will quickly 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 understand CQL queries, the only
thing it's aware of is the number of rows already read. Therefore we should allow an optional
parameter {{<initial_row_number>}} in {{QUERY}} and {{EXECUTE}} messages that would
allow a kind of stateless 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 administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message