0.6.5's release is being voted on now - http://www.mail-archive.com/d...@cassandra.apache.org/msg00788.html - so if all goes well, it will be out in a couple of days.
On Aug 25, 2010, at 9:04 AM, Moleza Moleza wrote: > That was the Fastest Response ever (about 10 seconds). > When is 0.6.5 being released? Any ETA? > Where is 0.6.5? isn't it in the subversion /cassandra-0.6 branch? > I did checkout that code yesterday and built it successfully. > Still it did not work, we had to revert back to 0.6.3. > Those bugs you mentioned talk about duplicate keys, not what I reported here. > Is there another code repository (svn) where I can get the FIX so I can test > it? > Thanks for your help > > On Wed, Aug 25, 2010 at 9:57 AM, Jonathan Ellis <jbel...@gmail.com> wrote: >> yes. known bug, fixed in 0.6.5 (CASSANDRA-1145, CASSANDRA-1042) >> >> On Wed, Aug 25, 2010 at 8:53 AM, Moleza Moleza <mole...@gmail.com> wrote: >>> HI, >>> We just recently tried to use 0.6.4 in our production environment and >>> had some serious problem. >>> The getRangeSlices functionality is broken. >>> We have a cluster of 5 machines. >>> We use getRangeSlices to iterate over all of the keys in a cf (2062 keys >>> total). >>> We are using OrderPreservingPartitioner. >>> We use getRangeSlices with KeyRange using keys (not tokens). >>> If we set the requestBlockCount (aka: KeyRange.setCount()) to a number >>> greater than 2062 we get all keys in one shot (all is good). >>> If we try to fetch the keys in smaller blocks (requestBlockCount=100) >>> we get BAD RESULTS. >>> We get only 800 unique keys back. >>> We start with (startKey="" and endKey="") then, after each iteration, >>> we set the startKey=lastMaxKey from the prior iteration (to get >>> lastMaxKey we use String.Compare to track the largest one from prior >>> iteration [we do this cause we assume keys might come back out of >>> order]). >>> Our keys are strings (obviously the only option in 0.6) that represent >>> numbers. >>> Some Sample keys are: (in correct lexi order) >>> -1 >>> 11113 >>> 11457 >>> 6831 >>> 7035 >>> 8060 >>> 8839 >>> ------ >>> This code (without any changes) was working correctly under 0.6.3 (we >>> got same response from getRangeSlices if using requestBlockCounts of >>> 10,000 or 100). >>> When we upgraded to 0.6.4 it stopped working. >>> We tried the 0.6 branch (built the classes and created a >>> cassandra.jar) but it still did not work. >>> We reverted back to 0.6.3 and (again, without changing the code) it >>> started working again. >>> -------- >>> One thing we learned is that when upgrading to the next version, we >>> better run a lot of tests to make sure something is not broken going >>> forward. >>> -------- >>> What gives? >>> Is this a known bug? I could not find anything in JIRA (only one about >>> RandomPartitioner). >>> Any Clues? >>> >> >> >> >> -- >> Jonathan Ellis >> Project Chair, Apache Cassandra >> co-founder of Riptano, the source for professional Cassandra support >> http://riptano.com >>
