You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2011/04/12 13:31:05 UTC
[jira] [Created] (CASSANDRA-2457) Batch_mutate is broken for
counters
Batch_mutate is broken for counters
-----------------------------------
Key: CASSANDRA-2457
URL: https://issues.apache.org/jira/browse/CASSANDRA-2457
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Fix For: 0.8
CASSANDRA-2384 allowed for batch_mutate to take counter and non counter operation, but the code was not updated correctly to handle that case. As it is, the code will use the first mutation in the batch list to decide whether to apply the write code path of counter or not, and will thus break if those are mixed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2457) Batch_mutate is broken for
counters
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-2457:
----------------------------------------
Attachment: 0001-Fix-batch_mutate-for-counters.patch
Attaching patch against 0.8.
Basically this makes SP.mutate() handle a list of mixed RowMutation and CounterMutation (but then each mutation use the right path). This is needed since a batch_mutate() can now mix those.
This has an unfortunate consequence however in that I don't think there is a way to distinguish the writeStats of standard insert of the ones of counter insert anymore, and thus this patch remove the latter ones (and count everything in writeStat).
> Batch_mutate is broken for counters
> -----------------------------------
>
> Key: CASSANDRA-2457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2457
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.8
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 0.8
>
> Attachments: 0001-Fix-batch_mutate-for-counters.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> CASSANDRA-2384 allowed for batch_mutate to take counter and non counter operation, but the code was not updated correctly to handle that case. As it is, the code will use the first mutation in the batch list to decide whether to apply the write code path of counter or not, and will thus break if those are mixed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2457) Batch_mutate is broken for
counters
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022063#comment-13022063 ]
Hudson commented on CASSANDRA-2457:
-----------------------------------
Integrated in Cassandra #859 (See [https://hudson.apache.org/hudson/job/Cassandra/859/])
merge CASSANDRA-2457 from 0.8
> Batch_mutate is broken for counters
> -----------------------------------
>
> Key: CASSANDRA-2457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2457
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.8
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 0.8
>
> Attachments: 0001-Fix-batch_mutate-for-counters-v2.patch, 0001-Fix-batch_mutate-for-counters.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> CASSANDRA-2384 allowed for batch_mutate to take counter and non counter operation, but the code was not updated correctly to handle that case. As it is, the code will use the first mutation in the batch list to decide whether to apply the write code path of counter or not, and will thus break if those are mixed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2457) Batch_mutate is broken for
counters
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021943#comment-13021943 ]
Stu Hood commented on CASSANDRA-2457:
-------------------------------------
+1
> Batch_mutate is broken for counters
> -----------------------------------
>
> Key: CASSANDRA-2457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2457
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.8
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 0.8
>
> Attachments: 0001-Fix-batch_mutate-for-counters-v2.patch, 0001-Fix-batch_mutate-for-counters.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> CASSANDRA-2384 allowed for batch_mutate to take counter and non counter operation, but the code was not updated correctly to handle that case. As it is, the code will use the first mutation in the batch list to decide whether to apply the write code path of counter or not, and will thus break if those are mixed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2457) Batch_mutate is broken for
counters
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022316#comment-13022316 ]
Stu Hood commented on CASSANDRA-2457:
-------------------------------------
Thanks Sylvain. Opened CASSANDRA-2522
> Batch_mutate is broken for counters
> -----------------------------------
>
> Key: CASSANDRA-2457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2457
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.8 beta 1
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 0.8 beta 1
>
> Attachments: 0001-Fix-batch_mutate-for-counters-v2.patch, 0001-Fix-batch_mutate-for-counters.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> CASSANDRA-2384 allowed for batch_mutate to take counter and non counter operation, but the code was not updated correctly to handle that case. As it is, the code will use the first mutation in the batch list to decide whether to apply the write code path of counter or not, and will thus break if those are mixed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2457) Batch_mutate is broken for
counters
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021071#comment-13021071 ]
Sylvain Lebresne commented on CASSANDRA-2457:
---------------------------------------------
Attached rebased version (post-CASSANDRA-2454 in particular)
bq. writeLocallyAndReplicate doesn't always perform a local mutation, so it should probably be renamed
Renamed it to performWrite (since it mostly simply imply a so-called writePerformer).
bq. Since mutateCounter and writeLocallyAndReplicate are symmetrical and are called depending on whether an IMutation is an instance of CounterMutation, could we move them onto IMutation, and polymorphically decide the behavior?
Hum, they are not really so symmetrical. In particular writeLocallyAndReplicate (or performWrite as it is called nowadays) really is polymorphic over the IMutation used.
So the only seem we we could do (at least easily) is moving some of mutateCounter in CounterMutation, but not sure it will look so great. Also, it is probably nice to keep all the code related to the write/read protocol in StorageProxy (doing otherwise would be like moving the query code out of CFStore, nobody wants that :D)
bq. I'm fine with this, since a counter is as "real" a write as any other. But I do think we should record the latencies for the replicate-on-write stage like we do for the read and mutation stages on a per column family basis. I can tackle it in a separate ticket if you'd like.
Make sense, but I'm also in favor of moving this to some other ticket.
> Batch_mutate is broken for counters
> -----------------------------------
>
> Key: CASSANDRA-2457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2457
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.8
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 0.8
>
> Attachments: 0001-Fix-batch_mutate-for-counters-v2.patch, 0001-Fix-batch_mutate-for-counters.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> CASSANDRA-2384 allowed for batch_mutate to take counter and non counter operation, but the code was not updated correctly to handle that case. As it is, the code will use the first mutation in the batch list to decide whether to apply the write code path of counter or not, and will thus break if those are mixed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2457) Batch_mutate is broken for
counters
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020037#comment-13020037 ]
Stu Hood commented on CASSANDRA-2457:
-------------------------------------
* writeLocallyAndReplicate doesn't always perform a local mutation, so it should probably be renamed
* Since mutateCounter and writeLocallyAndReplicate are symmetrical and are called depending on whether an IMutation is an instance of CounterMutation, could we move them onto IMutation, and polymorphically decide the behavior?
> ...and thus this patch remove the latter ones (and count everything in writeStat).
I'm fine with this, since a counter is as "real" a write as any other. _But_ I do think we should record the latencies for the replicate-on-write stage like we do for the read and mutation stages on a per column family basis. I can tackle it in a separate ticket if you'd like.
PS: Thanks for removing this line!
{code}mutations.iterator().next().getColumnFamilies().iterator().next().metadata().getDefaultValidator().isCommutative(){code}
Thanks Sylvain!
> Batch_mutate is broken for counters
> -----------------------------------
>
> Key: CASSANDRA-2457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2457
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.8
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 0.8
>
> Attachments: 0001-Fix-batch_mutate-for-counters.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> CASSANDRA-2384 allowed for batch_mutate to take counter and non counter operation, but the code was not updated correctly to handle that case. As it is, the code will use the first mutation in the batch list to decide whether to apply the write code path of counter or not, and will thus break if those are mixed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2457) Batch_mutate is broken for
counters
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-2457:
--------------------------------
Reviewer: stuhood
> Batch_mutate is broken for counters
> -----------------------------------
>
> Key: CASSANDRA-2457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2457
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.8
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 0.8
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> CASSANDRA-2384 allowed for batch_mutate to take counter and non counter operation, but the code was not updated correctly to handle that case. As it is, the code will use the first mutation in the batch list to decide whether to apply the write code path of counter or not, and will thus break if those are mixed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2457) Batch_mutate is broken for
counters
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-2457:
----------------------------------------
Attachment: 0001-Fix-batch_mutate-for-counters-v2.patch
> Batch_mutate is broken for counters
> -----------------------------------
>
> Key: CASSANDRA-2457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2457
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.8
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 0.8
>
> Attachments: 0001-Fix-batch_mutate-for-counters-v2.patch, 0001-Fix-batch_mutate-for-counters.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> CASSANDRA-2384 allowed for batch_mutate to take counter and non counter operation, but the code was not updated correctly to handle that case. As it is, the code will use the first mutation in the batch list to decide whether to apply the write code path of counter or not, and will thus break if those are mixed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira