Skip to content

Conversation

@vanzin
Copy link
Contributor

@vanzin vanzin commented Aug 5, 2015

First, it's probably a bad idea to call generated Scala methods
from Java. In this case, the method being called wasn't actually
"Utils.createTempDir()", but actually the method that returns the
first default argument to the actual createTempDir method, which
is just the location of java.io.tmpdir; meaning that all tests in
the class were using the same temp dir, and thus affecting each
other.

Second, spillingOccursInResponseToMemoryPressure was not writing
enough records to actually cause a spill.

First, it's probably a bad idea to call generated Scala methods
from Java. In this case, the method being called wasn't actually
"Utils.createTempDir()", but actually the method that returns the
first default argument to the actual createTempDir method, which
is just the location of java.io.tmpdir; meaning that all tests in
the class were using the same temp dir, and thus affecting each
other.

Second, spillingOccursInResponseToMemoryPressure was not writing
enough records to actually cause a spill.
@vanzin
Copy link
Contributor Author

vanzin commented Aug 5, 2015

/cc @rxin @JoshRosen

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has to be deleted in tearDown too I presume in order to fix this? or else it's still reusing a same dir?

I checked and there is a similar problem in some other Java tests:

JavaSaveLoadSuite
JavaMetastoreDataSourcesSuite
JavaAPISuite

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case no; setUp and tearDown are per-test, so each test gets a separate temp dir.

I'll take a look at the other tests. Might be worth it to add the temp dir helper method in some common java class.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh right it makes a subdir every time anyway. Well, it'd be better to clean up the temp dir in tearDown if possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'll do this. I'll fix this test this way, then file a separate bug to have a shared, Java createTempDir() and use it from everywhere. How does that sound?

This is the only unit test that consistently fails in our builds so I'd like to at least unblock it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually all the other tests you mention do the right thing. This is the only place that was calling the wrong Scala method.

@JoshRosen
Copy link
Contributor

Seems fine to me, pending Jenkins.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This didn't fail for me locally, which is kind of odd.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fails for me consistently if I use 100000.

Running org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorterSuite
Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.99 sec <<< FAILURE! - in org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorterSuite
spillingOccursInResponseToMemoryPressure(org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorterSuite)  Time elapsed: 0.426 sec  <<< FAILURE!
java.lang.AssertionError: 
Expected: a value equal to or greater than <1>
     got: <0>

        at org.junit.Assert.assertThat(Assert.java:780)
        at org.junit.Assert.assertThat(Assert.java:738)
        at org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorterSuite.spillingOccursInResponseToMemoryPressure(UnsafeExternalSorterSuite.java:243)

spillingOccursInResponseToMemoryPressure(org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorterSuite)  Time elapsed: 0.429 sec  <<< FAILURE!
java.lang.AssertionError: expected:<0> but was:<69206016>
        at org.junit.Assert.fail(Assert.java:93)
        at org.junit.Assert.failNotEquals(Assert.java:647)
        at org.junit.Assert.assertEquals(Assert.java:128)
        at org.junit.Assert.assertEquals(Assert.java:472)
        at org.junit.Assert.assertEquals(Assert.java:456)
        at org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorterSuite.tearDown(UnsafeExternalSorterSuite.java:150)


Results :

Failed tests: 
org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorterSuite.spillingOccursInResponseToMemoryPressure(org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorterSuite)
  Run 1: UnsafeExternalSorterSuite.spillingOccursInResponseToMemoryPressure:243 
Expected: a value equal to or greater than <1>
     got: <0>

  Run 2: UnsafeExternalSorterSuite.tearDown:150 expected:<0> but was:<69206016>

@SparkQA
Copy link

SparkQA commented Aug 5, 2015

Test build #39903 has finished for PR 7970 at commit a64f36a.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@vanzin
Copy link
Contributor Author

vanzin commented Aug 5, 2015

Well the test being changed did pass... retest this please.

@SparkQA
Copy link

SparkQA commented Aug 5, 2015

Test build #39909 timed out for PR 7970 at commit 74d357f after a configured wait of 175m.

@SparkQA
Copy link

SparkQA commented Aug 6, 2015

Test build #239 has finished for PR 7970 at commit 74d357f.

  • This patch fails PySpark unit tests.
  • This patch merges cleanly.
  • This patch adds the following public classes (experimental):
    • class BlockMatrix(DistributedMatrix):
    • // class DataFrame

@rxin
Copy link
Contributor

rxin commented Aug 6, 2015

I'm going to merge this.

asfgit pushed a commit that referenced this pull request Aug 6, 2015
First, it's probably a bad idea to call generated Scala methods
from Java. In this case, the method being called wasn't actually
"Utils.createTempDir()", but actually the method that returns the
first default argument to the actual createTempDir method, which
is just the location of java.io.tmpdir; meaning that all tests in
the class were using the same temp dir, and thus affecting each
other.

Second, spillingOccursInResponseToMemoryPressure was not writing
enough records to actually cause a spill.

Author: Marcelo Vanzin <vanzin@cloudera.com>

Closes #7970 from vanzin/SPARK-9651 and squashes the following commits:

74d357f [Marcelo Vanzin] Clean up temp dir on test tear down.
a64f36a [Marcelo Vanzin] [SPARK-9651] Fix UnsafeExternalSorterSuite.

(cherry picked from commit 4399b7b)
Signed-off-by: Reynold Xin <rxin@databricks.com>
@asfgit asfgit closed this in 4399b7b Aug 6, 2015
@SparkQA
Copy link

SparkQA commented Aug 6, 2015

Test build #39930 has finished for PR 7970 at commit 74d357f.

  • This patch fails PySpark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@vanzin vanzin deleted the SPARK-9651 branch August 6, 2015 20:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants