Uh oh!
There was an error while loading. Please reload this page.
[SPARK-25338][Test] Ensure to call super.beforeAll() and super.afterAll() in test cases - #22337
[SPARK-25338][Test] Ensure to call super.beforeAll() and super.afterAll() in test cases#22337kiszk wants to merge 8 commits into
Conversation
SparkQA
commented
Sep 5, 2018
Test build #95698 has finished for PR 22337 at commit
|
kiszk
commented
Sep 5, 2018
retest this please |
SparkQA
commented
Sep 5, 2018
Test build #95703 has finished for PR 22337 at commit
|
dongjoon-hyun
commented
Sep 6, 2018
Hi, @kiszk . Oh, did you check them all? Are these all of them? |
There was a problem hiding this comment.
It seems that we need try...finally for _sc.stop().
There was a problem hiding this comment.
Here, too. Let's use try to make it sure the invocation of super.afterAll().
Could you check the other suites like |
kiszk
commented
Sep 6, 2018
Sure, I just focused on files under |
SparkQA
commented
Sep 6, 2018
Test build #95748 has finished for PR 22337 at commit
|
kiszk
commented
Sep 6, 2018
There was a problem hiding this comment.
Oh, this one is beforeAll. Did you check beforeAll, too?
There was a problem hiding this comment.
Is it correct in this test suite context? We usually put super.afterAll() into finally. If there is no reason, let's fix this by switch them.
There was a problem hiding this comment.
In general, I agree with your opinion. I found some exceptional cases like this. Thus, I keep the original order.
Should we keep the original order or try to swap them?
There was a problem hiding this comment.
IMHO this is clearly an error and we should swap it
There was a problem hiding this comment.
Could you check the history of this too? Is there a reason for this StateStoreRDDSuite to put deleteRecursively at the end? For the other state store suite, super.afterAll is consistently before delete...
There was a problem hiding this comment.
I cannot find other state store suite. Could you please let me know the name of these suites?
I intentionally changed the order since I saw this order (deleteRecursively() ->super.afterAll()) in the following other places.
Since I am neutral on this order, it is ok to keep the original order like
try {
super.afterAll()
} finally {
Utils.deleteRecursively(new File(tempDir))
}
core/src/test/scala/org/apache/spark/rdd/RDDSuite.scala
core/src/test/scala/org/apache/spark/storage/DiskBlockManagerSuite.scala
sql/core/src/test/scala/org/apache/spark/sql/sources/CreateTableAsSelectSuite.scala
sql/core/src/test/scala/org/apache/spark/sql/sources/InsertSuite.scala
mllib/src/test/scala/org/apache/spark/ml/source/libsvm/LibSVMRelationSuite.scala
mllib/src/test/scala/org/apache/spark/ml/util/MLTest.scala
mllib/src/test/scala/org/apache/spark/ml/util/TempDirectory.scala
streaming/src/test/scala/org/apache/spark/streaming/rdd/MapWithStateRDDSuite.scala
There was a problem hiding this comment.
I prefer your change, too. But, the reason why I asked is that you didn't fix the order in FlatMapGroupsWithStateSuite in this PR. I want to make it sure whether there is a obvious reason or not.
There was a problem hiding this comment.
Sure, let me change the order in FlatMapGroupsWithStateSuite , too.
There was a problem hiding this comment.
Ur, are you sure? StreamingAggregationSuite, StreamTest, StreamingAggregationSuite and StreamingDeduplicationSuite also have reverse order for StateStore.stop().
There was a problem hiding this comment.
Hmm, I see. Let me keep the original order as
try {
super.afterAll()
} finally {
Utils.deleteRecursively(...)
}
Thank you for listing them out.
There was a problem hiding this comment.
@kiszk Just wanted to understand. Is there a reason that its not under finally block ?
There was a problem hiding this comment.
@kiszk Can sc.stop throw an exception ? If so, shouldn't we attempt to do a teardown first before calling super.afterAll() ?
There was a problem hiding this comment.
I'm confused by your comment, it looks like we try and stop the spark context first. Are you suggesting that we want to tear down kafka test utils even if the Spark stop context fails?
There was a problem hiding this comment.
@holdenk Please correct me on this one, in my understanding, we do 3 distinct things in the afterAll() method.
1) sc.stop 2) kafkaTestUtils.teardown() 3) super.afterAll()
Currently, even if we fail in (1) or (2) , we will always do (3) as its done in the finally block. My question was , if we fail at (1) , should we do (2) and (3) ? I don't know about the details of the test suite to know for sure if this matters or not. I was just curious.
There was a problem hiding this comment.
sc.stop can throw an exception. Thus, I updated this using nested try-finally.
There was a problem hiding this comment.
@kiszk Can sc.stop throw an exception ? If so, shouldn't we attempt to do a teardown first before calling super.afterAll() ?
SparkQA
commented
Sep 7, 2018
Test build #95805 has finished for PR 22337 at commit
|
SparkQA
commented
Sep 8, 2018
Test build #95822 has finished for PR 22337 at commit
|
SparkQA
commented
Sep 8, 2018
Test build #95821 has finished for PR 22337 at commit
|
kiszk
commented
Sep 8, 2018
retest this please |
SparkQA
commented
Sep 8, 2018
Test build #95832 has finished for PR 22337 at commit
|
SparkQA
commented
Sep 8, 2018
Test build #95833 has finished for PR 22337 at commit
|
There was a problem hiding this comment.
@kiszk . Let's remove with BeforeAndAfterAll and the whole afterAll(). These are redundant because we fixed afterAll in StreamTest already.
There was a problem hiding this comment.
Here, too. Let's remove the redundant with BeforeAndAfterAll and the whole afterAll function.
There was a problem hiding this comment.
Here, too. with BeforeAndAfterAll and override def afterAll() are redundant.
SparkQA
commented
Sep 11, 2018
Test build #95890 has finished for PR 22337 at commit
|
kiszk
commented
Sep 11, 2018
retest this please |
SparkQA
commented
Sep 11, 2018
Test build #95909 has finished for PR 22337 at commit
|
dongjoon-hyun
commented
Sep 11, 2018
Retest this please. |
SparkQA
commented
Sep 11, 2018
Test build #95917 has finished for PR 22337 at commit
|
kiszk
commented
Sep 11, 2018
retest this please |
SparkQA
commented
Sep 11, 2018
Test build #95938 has finished for PR 22337 at commit
|
kiszk
commented
Sep 11, 2018
retest this please |
commented
Sep 11, 2018
Test build #95958 has finished for PR 22337 at commit
|
commented
Sep 12, 2018
Ur, could you resolve the conflicts, @kiszk ? |
commented
Sep 13, 2018
Test build #96039 has finished for PR 22337 at commit
|
commented
Sep 13, 2018 •
Thank you, @kiszk . |
What changes were proposed in this pull request?
This PR ensures to call
super.afterAll()inoverride afterAll()method for test suites.super.afterAll()super.afterAll()only under certain conditionsuper.afterAll().This PR also ensures to call
super.beforeAll()inoverride beforeAll()for test suites.How was this patch tested?
Existing UTs