Actually the bug is in the Gaussian read test. In generates seek keys by using a Gaussian distribution with the mean of N/2 and a sigma of N/10 (N = number of rows used) and using this key directly to seek into the HFile. The HFile was seeded with keys from 0-N.
This will fail if we ever generate a key < 0, which is rare, but by no means impossible. We need to clamp the min and max values to 0 and 2*N, resp. -- Lars ________________________________ From: Jean-Marc Spaggiari <[email protected]> To: dev <[email protected]>; lars hofhansl <[email protected]> Sent: Sunday, February 16, 2014 10:59 AM Subject: Re: [VOTE] The 1st hbase 0.94.17 release candidate is available for download Running fully dist with Hadoop 1.2.1. Retried with 0.94.16 and got the same exception from time to time. So I don't think this will impact the release of 0.94.17. When my PE base line will be done, I will try the same with 0.96 + Hadoop 2.2.0 and see if I get the same exception. 2014-02-16 13:15 GMT-05:00 lars hofhansl <[email protected]>: Hmm... Do you see this in 0.94.17 only (but not in 0.94.16 or earlier)? >Are you running in local mode or with a real HDFS? > > >-- Lars > >----- Original Message ----- > >From: Jean-Marc Spaggiari <[email protected]> >To: dev <[email protected]> > >Cc: >Sent: Sunday, February 16, 2014 5:29 AM >Subject: Re: [VOTE] The 1st hbase 0.94.17 release candidate is available for >download > > >+1 to keep the default behavior. It's very nice to have to option to start >more than one thread but I think for 0.94 we should keep default config. >But also, it's not a big thing. So I will be only -0 for this in the RC. I >agree that it's a bit surprising the see the 3 servers, but not that >dramatic. > >Also I'm getting this once in a while when doing HFilePerformanceEvaluation: > >org.apache.hadoop.hbase.io.hfile.AbstractHFileReader$NotSeekedException: >Not seeked to a key/value > at >org.apache.hadoop.hbase.io.hfile.AbstractHFileReader$Scanner.assertSeeked(AbstractHFileReader.java:320) > at >org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.next(HFileReaderV2.java:690) > at >org.apache.hadoop.hbase.HFilePerformanceEvaluation$GaussianRandomReadBenchmark.doRow(HFilePerformanceEvaluation.java:347) > at >org.apache.hadoop.hbase.HFilePerformanceEvaluation$RowOrientedBenchmark.run(HFilePerformanceEvaluation.java:169) > at >org.apache.hadoop.hbase.HFilePerformanceEvaluation.runBenchmark(HFilePerformanceEvaluation.java:121) > at >org.apache.hadoop.hbase.HFilePerformanceEvaluation$3.run(HFilePerformanceEvaluation.java:97) > at java.lang.Thread.run(Thread.java:744) > >Occured 30% of the time, and only on GaussianRandomReadBenchmark. > >JM > > > >2014-02-16 2:32 GMT-05:00 Andrew Purtell <[email protected]>: > >> On Sat, Feb 15, 2014 at 9:18 PM, lars hofhansl <[email protected]> wrote: >> >> > Actually looks like this was by design in HBASE-10340/HBASE-9892. >> > It spawns three local region server threads in local mode now, still just >> > one process. >> > >> > I now think it's OK. What do other folks think? Should we set the default >> > back to 1? >> > >> >> I think unannounced things that violate the principle of least surprise are >> bad. We should sink the RC and set the default back IMO. >> >> >> >> -- >> Best regards, >> >> - Andy >> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein >> (via Tom White) >> > >
