You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2009/05/03 16:12:30 UTC
[jira] Created: (CASSANDRA-128) Hinted handoff improvements
Hinted handoff improvements
---------------------------
Key: CASSANDRA-128
URL: https://issues.apache.org/jira/browse/CASSANDRA-128
Project: Cassandra
Issue Type: Improvement
Reporter: Jonathan Ellis
Fix For: 0.4
- now that we have range queries we can split the HH keys across a standard CF instead of a single row in a super CF
- should GC tombstones instantly post-handoff since that data is only local (no need to worry about RR which is the point of tombstoning)
- waiting for ack-per-key in HHM.sendMessage is going to really slow things down since you spend most of your time waiting for acks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-128) Hinted handoff improvements
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-128:
-------------------------------------
Fix Version/s: (was: 0.4)
> Hinted handoff improvements
> ---------------------------
>
> Key: CASSANDRA-128
> URL: https://issues.apache.org/jira/browse/CASSANDRA-128
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Priority: Minor
>
> - now that we have range queries we can split the HH keys across a standard CF instead of a single row in a super CF
> - should GC tombstones instantly post-handoff since that data is only local (no need to worry about RR which is the point of tombstoning)
> - waiting for ack-per-key in HHM.sendMessage is going to really slow things down since you spend most of your time waiting for acks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-128) Hinted handoff improvements
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706070#action_12706070 ]
Jonathan Ellis commented on CASSANDRA-128:
------------------------------------------
4. from CASSANDRA-34 by Jun Rao: It's probably worthwhile to make intervalInMins_ in HHM configurable.
> Hinted handoff improvements
> ---------------------------
>
> Key: CASSANDRA-128
> URL: https://issues.apache.org/jira/browse/CASSANDRA-128
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Fix For: 0.4
>
>
> - now that we have range queries we can split the HH keys across a standard CF instead of a single row in a super CF
> - should GC tombstones instantly post-handoff since that data is only local (no need to worry about RR which is the point of tombstoning)
> - waiting for ack-per-key in HHM.sendMessage is going to really slow things down since you spend most of your time waiting for acks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-128) Hinted handoff improvements
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-128:
-------------------------------------
Description:
- should GC tombstones instantly post-handoff since that data is only local (no need to worry about RR which is the point of tombstoning)
- waiting for ack-per-key in HHM.sendMessage is going to really slow things down since you spend most of your time waiting for acks
was:
- now that we have range queries we can split the HH keys across a standard CF instead of a single row in a super CF
- should GC tombstones instantly post-handoff since that data is only local (no need to worry about RR which is the point of tombstoning)
- waiting for ack-per-key in HHM.sendMessage is going to really slow things down since you spend most of your time waiting for acks
Originally included
- now that we have range queries we can split the HH keys across a standard CF instead of a single row in a super CF
Answer is no, we don't want to make HH dependent on partitioner type.
> Hinted handoff improvements
> ---------------------------
>
> Key: CASSANDRA-128
> URL: https://issues.apache.org/jira/browse/CASSANDRA-128
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jonathan Ellis
> Priority: Minor
>
> - should GC tombstones instantly post-handoff since that data is only local (no need to worry about RR which is the point of tombstoning)
> - waiting for ack-per-key in HHM.sendMessage is going to really slow things down since you spend most of your time waiting for acks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-128) Hinted handoff improvements
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-128:
-------------------------------------
Priority: Minor (was: Major)
> Hinted handoff improvements
> ---------------------------
>
> Key: CASSANDRA-128
> URL: https://issues.apache.org/jira/browse/CASSANDRA-128
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Priority: Minor
> Fix For: 0.4
>
>
> - now that we have range queries we can split the HH keys across a standard CF instead of a single row in a super CF
> - should GC tombstones instantly post-handoff since that data is only local (no need to worry about RR which is the point of tombstoning)
> - waiting for ack-per-key in HHM.sendMessage is going to really slow things down since you spend most of your time waiting for acks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.