[
https://issues.apache.org/jira/browse/CASSANDRA-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051329#comment-13051329
]
Yang Yang edited comment on CASSANDRA-2103 at 6/17/11 9:27 PM:
---------------------------------------------------------------
there could be a problem with trying to rely on forcing compaction order:
if you base the intended order on max timestamp of each sstable, the timestamp
is not trustworthy, because a single malicious client request can bump up its
timestamp to the future, and arbitrarily change the order of compaction, thus
rendering the approach in 2735 useless.
you can't base the order on the physical sstable flush time either, since
different nodes have different flush times.
overall I think trying to fix the compaction order is not the correction
direction to attack this problem: the issue here is due to the changing order
between *individual counter adds/deletes* (auto-expire is same as delete), this
order can be different between different counters, so you have to fix the order
between the updates within each counter, *not the order between ensembles of
counters*. such ensembles of counters do not guarantee any orders at all, due
to randomness in flushing time, or message delivery (they have similar effects)
was (Author: yangyangyyy):
there could be a problem with trying to rely on forcing compaction order:
if you base the intended order on max timestamp of each sstable, the timestamp
is not trustworthy, because a single malicious client request can bump up its
timestamp to the future, and arbitrarily change the order of compaction, thus
rendering the approach in 2735 useless.
you can't base the order on the physical sstable flush time either, since
different nodes have different flush times.
overall I think trying to fix the compaction order is not the correction
direction to attack this problem: the issue here is due to the changing order
between *individual counter adds/deletes(auto-expire is same as delete)*, this
order can be different between different counters, so you have to fix the order
between the updates within each counter, *not the order between ensembles of
counters*. such ensembles of counters do not guarantee any orders at all, due
to randomness in flushing time, or message delivery (they have similar effects)
> expiring counter columns
> ------------------------
>
> Key: CASSANDRA-2103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2103
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Affects Versions: 0.8 beta 1
> Reporter: Kelvin Kakugawa
> Attachments: 0001-CASSANDRA-2103-expiring-counters-logic-tests.patch
>
>
> add ttl functionality to counter columns.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
