mr related tests may fail for

https://issues.apache.org/jira/browse/HBASE-8324

- liushaohui

On 10/12/2013 05:03 AM, Stack wrote:
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


Reply via email to