We already have 3 binding +1s, so the vote has passed. J-D
On Mon, Oct 4, 2010 at 8:38 PM, Stack <st...@duboce.net> wrote: > On Mon, Oct 4, 2010 at 4:56 PM, Ryan Rawson <ryano...@gmail.com> wrote: >> I ran ycsb on it for a while and it looked ok... but we really cant >> ship without the fix to that bug, it has the possibility of causing >> serious data loss for heavy users of ICV. >> > > We can ship the DR though, right? 0.90.0RC1 is just around the corner! > St.Ack > > >> -ryan >> >> On Mon, Oct 4, 2010 at 3:41 PM, Jonathan Gray <jg...@facebook.com> wrote: >>> +1 >>> >>> I took it for a test drive today and tested all the basic stuff. No >>> performance stuff but I think enough for my vote. >>> >>> JG >>> >>>> -----Original Message----- >>>> From: jdcry...@gmail.com [mailto:jdcry...@gmail.com] On Behalf Of Jean- >>>> Daniel Cryans >>>> Sent: Monday, October 04, 2010 10:56 AM >>>> To: dev@hbase.apache.org >>>> Subject: Re: [VOTE] Release 'development release' HBase 0.89.2010924 >>>> rc1? >>>> >>>> My vote is obviously +1, although we hit a bug this weekend regarding >>>> HBASE-3008 (for which we'll post a patch soon). Over time, the >>>> memstore size of regions with ICVs grows negative, which means that >>>> those regions can't flush and when you close them you basically lose >>>> all the data since the last flush (since on close it won't flush >>>> either). We solved this by disabling ICVs to those tables (basically >>>> setting the async ICV queues in the thrift servers to -1), copied the >>>> data to another cluster, restarted the cluster with the fix, >>>> re-imported the data, then re-enabled the ICVs. >>>> >>>> I don't think this is a blocker for a DR, as it only affects users >>>> doing only tons of ICVs on particular tables, but it should be >>>> disclosed somewhere. >>>> >>>> J-D >>>> >>>> On Fri, Sep 24, 2010 at 4:03 PM, Jean-Daniel Cryans >>>> <jdcry...@apache.org> wrote: >>>> > The 0.89.20100830 DR branch was cancelled, here's the new RC off a >>>> new branch. >>>> > >>>> > As discussed, this release candidate contains a revert of HBASE-2694 >>>> > which means that it is back on the "very" old master. It is also very >>>> > similar to what we run here in production. >>>> > >>>> > Sources and binaries can be found here: >>>> > >>>> > http://people.apache.org/~jdcryans/hbase-0.89.20100924-candidate-1/ >>>> > >>>> > Documentation: >>>> > >>>> > http://people.apache.org/~jdcryans/hbase-0.89.20100924-candidate- >>>> 1/hbase-0.89.20100924/docs/ >>>> > >>>> > Here's the list of everything I added since moving from 0830: >>>> > >>>> > HBASE-3008 Memstore.updateColumnValue passes wrong flag to >>>> heapSizeChange >>>> > HBASE-3035 Bandaid for HBASE-2990 >>>> > HBASE-2643 Figure how to deal with eof splitting logs >>>> > HBASE-2941 port HADOOP-6713 - threading scalability for RPC reads - >>>> to HBase >>>> > HBASE-3006 Reading compressed HFile blocks causes way too many DFS >>>> RPC calls >>>> > severly impacting performance >>>> > HBASE-2989 [replication] RSM won't cleanup after locking if 0 peers >>>> > HBASE-2992 [replication] MalformedObjectNameException in >>>> ReplicationMetrics >>>> > HBASE-3034 Revert the regions assignment part of HBASE-2694 (and >>>> > pals) for 0.89 >>>> > HBASE-3033 [replication] ReplicationSink.replicateEntries >>>> improvements >>>> > HBASE-2997 Performance fixes - profiler driven >>>> > HBASE-2889 Tool to look at HLogs -- parse and tail -f (patch #2 >>>> only) >>>> > >>>> > Unfortunately I forgot to add HBASE-2986 like Stack asked (sorry, I >>>> > just figured it while reading the old voting thread). >>>> > >>>> > Should we release this as the next "Development Release"? Please cast >>>> > your vote by Wednesday, September 29th. >>>> > >>>> > Thanks, >>>> > >>>> > The HBase Team >>>> > >>> >> >
