Re: MerkleTree.RowHash maybe a bug.

Hi Stu Hood, Yes, it may not result in extra repair, since the excess bytes of the Buffer may be same on different machine. e.g: all 0 bytes. But it depends on how the JDK (ByteArrayOutputStream) allocate memory, it is a risk for different JDK version. In fact, we have added compression feature i

Re: [VOTE] 0.6.8 RC2

+1 On Thu, Nov 11, 2010 at 17:39, Eric Evans wrote: > > A regression caused by CASSANDRA-1622[1] (and fixed in CASSANDRA-1727[2]) > made its way into the last release. With that fixed now (along with an > 11th hour backport of CASSANDRA-1722[3]), I propose the following > artifacts for 0.6.8. > >

Re: [VOTE] 0.6.8 RC2

+1 -Chris On Nov 11, 2010, at 3:39 PM, Eric Evans wrote: > > A regression caused by CASSANDRA-1622[1] (and fixed in CASSANDRA-1727[2]) > made its way into the last release. With that fixed now (along with an > 11th hour backport of CASSANDRA-1722[3]), I propose the following > artifacts for 0.6

Re: [VOTE] 0.6.8 RC2

On Thu, Nov 11, 2010 at 5:39 PM, Eric Evans wrote: > > A regression caused by CASSANDRA-1622[1] (and fixed in CASSANDRA-1727[2]) > made its way into the last release. With that fixed now (along with an > 11th hour backport of CASSANDRA-1722[3]), I propose the following > artifacts for 0.6.8. > >

Re: [VOTE] 0.6.8 RC2

+1 On Thu, Nov 11, 2010 at 5:39 PM, Eric Evans wrote: > > A regression caused by CASSANDRA-1622[1] (and fixed in CASSANDRA-1727[2]) > made its way into the last release. With that fixed now (along with an > 11th hour backport of CASSANDRA-1722[3]), I propose the following > artifacts for 0.6.8. >

[VOTE] 0.6.8 RC2

A regression caused by CASSANDRA-1622[1] (and fixed in CASSANDRA-1727[2]) made its way into the last release. With that fixed now (along with an 11th hour backport of CASSANDRA-1722[3]), I propose the following artifacts for 0.6.8. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandr

Re: [VOTE] 0.6.8 RC1

-1 1722 was just backported to the 0.6 branch (r1034172): I think we'll need to reroll... sorry! https://issues.apache.org/jira/browse/CASSANDRA-1722 On Thu, Nov 11, 2010 at 4:51 PM, Eric Evans wrote: > On Thu, 2010-11-11 at 14:44 -0600, Jo

Re: [VOTE] 0.6.8 RC1

On Thu, 2010-11-11 at 14:44 -0600, Jonathan Ellis wrote: > For the record, the regression was caused by 1622, noticed in testing > for 1719, and fixed in 1727. :) What's that you say? You want a recipe for carrot cake? -- Eric Evans eev...@rackspace.com

Re: [VOTE] 0.6.8 RC1

On Thu, Nov 11, 2010 at 2:43 PM, Eric Evans wrote: > > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-...@r1034097 > 0.6.8 artifacts: http://people.apache.org/~eevans +1 > I'd be happy to make an exception here and shorten the voting period to > expedite this release (say

Re: [VOTE] 0.6.8 RC1

For the record, the regression was caused by 1622, noticed in testing for 1719, and fixed in 1727. :) +1 on the release from me, and I'm okay with expediting it. On Thu, Nov 11, 2010 at 2:43 PM, Eric Evans wrote: > > We had a regression in the way of CASSANDRA-1719[1] make its way into > the las

[VOTE] 0.6.8 RC1

We had a regression in the way of CASSANDRA-1719[1] make its way into the last release. With that fixed now, I'd like to propose the following artifacts for 0.6.8. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-...@r1034097 0.6.8 artifacts: http://people.apache.org/~eevans I'

RE: MerkleTree.RowHash maybe a bug.

At first glance, this appeared to be a very egregious bug, but the effect is actually minimal: since the size of the buffer is deterministic based on the size of the data, you will have equal amounts of excess/junk data for equal rows. Combined with the fact that 0.6 doesn't reuse these buffers,

MerkleTree.RowHash maybe a bug.

Hi JE, 0.6.6: org.apache.cassandra.service.AntiEntropyService I found the rowHash method uses "row.buffer.getData()" directly. Since row.buffer.getData() is a byte[], and there may have some junk bytes in the end by the buffer, I think we should use the exact length. private MerkleTree.