incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: 0.3 and the OOM gremlin (CASSANDRA-208)
Date Wed, 03 Jun 2009 23:48:32 GMT
So, in light of Sandeep's point, I think I would prefer to do 0.3 now,
and try to do a short 0.4 cycle with current trunk and

 - the sstable redesign to address OOM problem
 - multitable support
 - patch to reduce logging impact so we look better in benchmarks :)
 - fsync fix
 - r/m old get_slice and rename get_slice_from to get_slice

How does that sound?

-Jonathan

On Wed, Jun 3, 2009 at 4:59 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
> You are right.  Of course, there's no sense in making such a tool
> harder to write than it needs to be.
>
> But I don't care that strongly since I won't be writing it. :P
>
> -Jonathan
>
> On Wed, Jun 3, 2009 at 4:53 PM, Sandeep Tata <sandeep.tata@gmail.com> wrote:
>> Won't things like multi-table support break binary compatibility anyway?
>>
>> We might be stuck with having to write a tool that migrates from a 0.3
>> format to a 0.4 format.
>>
>>
>> On Wed, Jun 3, 2009 at 2:44 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
>>> The fix for 208 [1] is fairly invasive.  should we
>>>
>>> (a) release another RC and do more testing before 0.3 final, or
>>> (b) release 0.3 without these changes, and only add this fix to trunk?
>>>
>>> Although I see the 0.3 release primarily as a means to let people
>>> start playing with the cassandra data model, I don't know that I want
>>> to release it knowing that 0.4 is going to be binary-incompatible with
>>> the 0.3 data files.  So I'd be inclined towards (a).
>>>
>>> [1] https://issues.apache.org/jira/browse/CASSANDRA-208
>>>
>>> -Jonathan
>>>
>>
>

Mime
View raw message