[jira] [Commented] (CASSANDRA-2495) Add a proper retry mechanism for counters in case of failed request

["Yang Yang (JIRA)" <ji...@apache.org>]

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

Yang Yang commented on CASSANDRA-2495:
--------------------------------------

interesting  topic, some thoughts that popped into my mind:

this ultimately requires that you keep a *history* of all counter updates, instead of just keeping the current counter value;
the marker for each add is essentially this history. 

then the issue is : how long do you keep the history? for use cases that do really frequent adds of small deltas, the history can be huge, 


you can limit the number of adds that require a history/marker to be kept for future verification , if you just don't keep a marker if a counter update is completely successful; also for each future update on the same counter, we only write a marker if this is specifically declared to be a retry attempt. ----- there is no need to guarantee that every pair of updates with the same uuidClient has to be de-duped, the client should bear that responsibility.

> Add a proper retry mechanism for counters in case of failed request
> -------------------------------------------------------------------
>
>                 Key: CASSANDRA-2495
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2495
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 0.8 beta 1
>            Reporter: Sylvain Lebresne
>         Attachments: marker_idea.txt
>
>
> Contrarily to standard insert, counter increments are not idempotent. As such, replaying a counter mutation when a TimeoutException occurs could lead to an over-count. This alone limits the use cases for which counters are a viable solution, so we should try to come up with a mechanism that allow the replay of a failed counter mutation without the risk of over-count. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira