This is due to an (unfortunate) difference in semantics between the two block managers in how each of them handles block existence: - The log block manager uses a giant in-memory map. As such, it's easy to guarantee that a block is only added to that map at the very end of the block writing process, when the block is closed. - The file block manager uses the underlying filesystem as its "map", so a block "exists" from the moment that it's opened for writing, as that's when the block's on-disk file is opened for writing too.
In this particular case, the test keeps its DeltaFileWriter in scope when testing the block for existence. Regardless of the block manager, WritableBlock::Abort() has yet to run, but because of the above semantics, the log block manager cannot find the block while the file block manager can. A simple fix is to let the DeltaFileWriter go out of scope before testing the block for existence. I tested this and the test passes with both block managers. I'm happy to push it, but I wonder whether the better approach would be to explicitly Abort() the block in DeltaFileWriter::Finish() in the zero delta case. Todd, what do you think? On Fri, Jun 3, 2016 at 10:33 AM, Todd Lipcon <t...@cloudera.com> wrote: > Misty's deltafile-test failure looks like a bug in FileBlockManager where > Abort() isn't removing an in-progress block. I can repro on Linux if I use > this block manager. Since this isn't recommended for production use, I dont > think this failing test case is a big deal. > > -Todd > > On Fri, Jun 3, 2016 at 6:23 PM, Misty Stanley-Jones < > mstanleyjo...@cloudera.com> wrote: > >> I'll talk to myself and paste more relevant info about the test failure in >> my previous email: >> >> [ RUN ] TestDeltaFile.TestEmptyFileIsAborted >> I0603 10:12:40.082170 2115547136 fs_manager.cc:345] Generated new instance >> metadata in path /tmp/test/instance: >> uuid: "566809d53e70414aac14dad13677795e" >> format_stamp: "Formatted at 2016-06-03 17:12:40 on cheezel.local" >> I0603 10:12:40.087999 2115547136 fs_manager.cc:242] Opened local >> filesystem: /tmp/test >> uuid: "566809d53e70414aac14dad13677795e" >> format_stamp: "Formatted at 2016-06-03 17:12:40 on cheezel.local" >> >> /Users/misty/kudu_rc/apache-kudu-incubating-0.9.0/src/kudu/tablet/deltafile-test.cc:384: >> Failure >> Value of: s.IsNotFound() >> Actual: false >> Expected: true >> OK >> >> On Fri, Jun 3, 2016 at 10:16 AM, Misty Stanley-Jones < >> mstanleyjo...@cloudera.com> wrote: >> >> > +1 >> > >> > Built on OSX, no problems. >> > Several tests failed when I ran make test, but I got all of them but >> > deltafile-test to pass when run individually. I think the failures >> during make >> > test are a known OSX issue. Here is the failure for deltafile-test: >> > >> > [ FAILED ] TestDeltaFile.TestEmptyFileIsAborted (11 ms) >> > [----------] 8 tests from TestDeltaFile (697 ms total) >> > >> > [----------] Global test environment tear-down >> > [==========] 8 tests from 1 test case ran. (697 ms total) >> > [ PASSED ] 7 tests. >> > [ FAILED ] 1 test, listed below: >> > [ FAILED ] TestDeltaFile.TestEmptyFileIsAborted >> > >> > On Wed, Jun 1, 2016 at 7:09 PM, Jean-Daniel Cryans <jdcry...@apache.org> >> > wrote: >> > >> >> Hi, >> >> >> >> We're happy to announce the first release candidate for Apache Kudu >> >> (incubating) 0.9.0. >> >> >> >> We are doing time-based releases leading up to 1.0.0 towards the end of >> >> the >> >> summer, with one 0.x.0 release every two months. >> >> >> >> The is a source-only release. The artifacts were staged here: >> >> https://dist.apache.org/repos/dist/dev/incubator/kudu/0.9.0-RC1/ >> >> >> >> It was built from this tag: >> >> >> >> >> https://git-wip-us.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=5f2bf643d8ce3d042aa3903543a92841077a6874 >> >> >> >> The release notes can be found here (some links will only work when this >> >> version is released): >> >> >> >> >> https://github.com/apache/incubator-kudu/blob/master/docs/release_notes.adoc#rn_0.9.0 >> >> >> >> KEYS file: >> >> http://www.apache.org/dist/incubator/kudu/KEYS >> >> >> >> I'd suggest going through the README, building Kudu, and running the >> unit >> >> tests. >> >> >> >> Please try the release and vote; vote will be open for at least 72 >> hours. >> >> >> >> Thanks, >> >> >> >> J-D >> >> >> > >> > >> > > > > -- > Todd Lipcon > Software Engineer, Cloudera