Anyone tried the 2.2 hadoop that is up for vote at the moment? I tried our unit tests and got these failures:
Failed tests: testCopyTable(org.apache.hadoop.hbase.mapreduce.TestCopyTable): expected:<0> but was:<1> testStartStopRow(org.apache.hadoop.hbase.mapreduce.TestCopyTable): expected:<0> but was:<1> testMultithreadedTableMapper(org.apache.hadoop.hbase.mapreduce.TestMultithreadedTableMapper) testSimpleCase(org.apache.hadoop.hbase.mapreduce.TestImportExport) testMetaExport(org.apache.hadoop.hbase.mapreduce.TestImportExport) testExportScannerBatching(org.apache.hadoop.hbase.mapreduce.TestImportExport) testWithFilter(org.apache.hadoop.hbase.mapreduce.TestImportExport) testWithDeletes(org.apache.hadoop.hbase.mapreduce.TestImportExport) testExcludeMinorCompaction(org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat) testMRIncrementalLoad(org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat) testMRIncrementalLoadWithSplit(org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat) testMROnTable(org.apache.hadoop.hbase.mapreduce.TestImportTsv): expected:<0> but was:<1> testMROnTableWithCustomMapper(org.apache.hadoop.hbase.mapreduce.TestImportTsv): expected:<0> but was:<1> testBulkOutputWithTsvImporterTextMapper(org.apache.hadoop.hbase.mapreduce.TestImportTsv): expected:<0> but was:<1> testBulkOutputWithAnExistingTable(org.apache.hadoop.hbase.mapreduce.TestImportTsv): expected:<0> but was:<1> testMROnTableWithTimestamp(org.apache.hadoop.hbase.mapreduce.TestImportTsv): expected:<0> but was:<1> testBulkOutputWithoutAnExistingTable(org.apache.hadoop.hbase.mapreduce.TestImportTsv): expected:<0> but was:<1> testRowCounterNoColumn(org.apache.hadoop.hbase.mapreduce.TestRowCounter) testRowCounterHiddenColumn(org.apache.hadoop.hbase.mapreduce.TestRowCounter) testRowCounterExclusiveColumn(org.apache.hadoop.hbase.mapreduce.TestRowCounter) testCombiner(org.apache.hadoop.hbase.mapreduce.TestTableMapReduce) testMultiRegionTable(org.apache.hadoop.hbase.mapreduce.TestTableMapReduce) testScanEmptyToAPP(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan1) testScanEmptyToBBA(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan1) testScanEmptyToBBB(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan1) testScanEmptyToOPP(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan1) testScanEmptyToEmpty(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan1) testWALPlayer(org.apache.hadoop.hbase.mapreduce.TestWALPlayer): expected:<0> but was:<1> testScanYZYToEmpty(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan2) testScanOPPToEmpty(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan2) testScanYYXToEmpty(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan2) testScanOBBToOPP(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan2) testScanOBBToQPP(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan2) testScanFromConfiguration(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan2) testScanYYYToEmpty(org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan2) testExportFileSystemState(org.apache.hadoop.hbase.snapshot.TestExportSnapshot): expected:<0> but was:<1> testSnapshotWithRefsExportFileSystemState(org.apache.hadoop.hbase.snapshot.TestExportSnapshot): expected:<0> but was:<1> Anyone else seeing this? St.Ack On Fri, Oct 11, 2013 at 10:05 AM, Stack <[email protected]> wrote: > On Thu, Oct 10, 2013 at 6:39 PM, Sergey Shelukhin > <[email protected]>wrote: > >> >Can we agree if the IT tests are green for a certain number of runs in a >> row, then it's stable? >> >> What do you mean by IT tests are green? Ours are mostly green lately >> (except for recently fixed bugs). >> Can you please share some investigation details? Maybe file bugs with >> description of symptoms, like logs and stuff; are you sure you are hitting >> 9696 in particular? >> > > We've been trying to keep up HBASE-9696 w/ ongoing notes. We should do > better for sure but big picture is that we have evidence that what is in > HBASE-9696 is an improvement over what we have now having had two sustained > runs w/o data loss. The fix is needed so we can do long-running hbase-it > suites; w/o it we were just crash-landing a few hours in. > > >> 9696 is a very big patch too, it can introduce more bugs and will require >> more fixing. >> We do need to have some deadline where large/risky changes cannot go imho. >> >> >> > Agree but after reviews, I do not know how to avoid it (see 9696 and its > RB) > > I suggest we commit hbase-9696 as is since it an incompatible change with > its introduction of two new states, states that we do not seem to be able > to do without. Then I cut an RC. If further issue in 9696, we can fine > tune/bug-fix post release. > > On another note, a rig run that has been going for almost 24 hours has > gone further than any run of the last few weeks. That is good. > > Let us know if need any more info/insight. Almost there. > St.Ack >
