incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Oskarsson <jo...@oskarsson.nu>
Subject Re: [DISCUSSION] High-volume counters in Cassandra
Date Fri, 24 Sep 2010 12:10:06 GMT
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 <johan@oskarsson.nu> 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 <tcurdt@apache.org> 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
> http://riptano.com


Mime
View raw message