incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Hanna <>
Subject Re: [DISCUSSION] High-volume counters in Cassandra
Date Fri, 24 Sep 2010 13:00:01 GMT
I'm all for some kind of some kind of compromise. It doesn't appear to
be a niche use case for just one company. Twitter, Digg, and SimpleGeo
and several others have said they will be using high volume counters.

They have already cleaned things up and separated it out. I don't know
all the details on the reservations to let it in but it seems like
some compromise could be found so that the feature could make it into

On Sep 24, 2010, at 7:10 AM, Johan Oskarsson <> wrote:

> Here is an update to where we are at with the counters.
> As promised we have published a new patch that adds a separate api method, marked experimental,
for the counters in CASSANDRA-1072.
> The discussion has now moved to CASSANDRA-1502, a ticket that suggests the internal IClock,
reconciler and other classes essential for 1072 should be removed. Doing so would not only
severely delay the addition of counters to Cassandra but force a grounds up redesign of 1072
that we believe would not improve the patch. This belief is based on the prototyping Kelvin
did for the work that has been refined into 1072.
> Since the overwhelming consensus of this discussion thread was that the patch is valuable
to the community and worthy of going in, we feel that it should be committed in approximately
its current form.
> While we work with the Apache community to resolve this issue we’ve decided to put
up a temporary version of Cassandra that includes the counters on the Twitter Github account.
> This is a step in releasing some of the systems we’ve built on top of this patch to
the open source community in the near future.
> On 6 sep 2010, at 21.19, Jonathan Ellis wrote:
>> Yes.
>> On Mon, Sep 6, 2010 at 12:11 PM, Johan Oskarsson <> wrote:
>>> The consensus in this thread seems to be moving towards the following todos in
order to get 1072 into trunk.
>>> * create separate api methods for increments
>>> * mark functionality as experimental
>>> * further code cleanup (please comment on jira with specific suggestions)
>>> Is this a reasonable summary? We'll keep this thread updated as the work progresses.
>>> /Johan
>>> On 6 sep 2010, at 16.47, Jonathan Ellis wrote:
>>>> On Thu, Sep 2, 2010 at 4:10 PM, Torsten Curdt <> wrote:
>>>>> The feature could still be marked experimental.
>>>>> That should loosen the contract a little. But at least it would be
>>>>> something to work with.
>>>> Maybe this is the best approach, post- code cleanup.  Although I'm
>>>> reluctant to add code with known, significant limitations, the problem
>>>> domain seems to be one with no silver bullets.
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder of Riptano, the source for professional Cassandra support

View raw message