-
Notifications
You must be signed in to change notification settings - Fork 28.7k
[SQL][minor] simplify a test to fix the maven tests #16244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@@ -98,20 +98,15 @@ class CodeGenerationSuite extends SparkFunSuite with ExpressionEvalHelper { | |||
} | |||
|
|||
test("SPARK-18091: split large if expressions into blocks due to JVM code size limit") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cloud-fan Just confirming, have you made sure that this test fails without the fix for SPARK-18091?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you mean? this test was added by SPARK-18091
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test simulates the scenario where large code for components of If expression causes JVM's method code size limit to be hit. So the point of having this test is if it fails before the fix for SPARK-18091 was committed and it passes afterwards. By failure I mean it gets terminated due to the method code size limit exceeded exception.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea of course, I reverted SPARK-18091 and ran this test locally, it failed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great!
How do we make sure the fixed test passes Maven-based tests? Manually? |
Actually I can't reproduce this issue locally, but by looking at the logs, I'm 90% percent sure this is the cause. The only way to verify it may be merging and checking the jenkins maven status again. |
Test build #69955 has finished for PR 16244 at commit
|
sgtm |
@cloud-fan Ok. I see. LGTM. |
## What changes were proposed in this pull request? After #15620 , all of the Maven-based 2.0 Jenkins jobs time out consistently. As I pointed out in #15620 (comment) , it seems that the regression test is an overkill and may hit constants pool size limitation, which is a known issue and hasn't been fixed yet. Since #15620 only fix the code size limitation problem, we can simplify the test to avoid hitting constants pool size limitation. ## How was this patch tested? test only change Author: Wenchen Fan <[email protected]> Closes #16244 from cloud-fan/minor. (cherry picked from commit 9abd05b) Signed-off-by: Sean Owen <[email protected]>
Merged to master, 2.1 and 2.0, in order to see if this resolves the test failures for 2.0 |
## What changes were proposed in this pull request? After #15620 , all of the Maven-based 2.0 Jenkins jobs time out consistently. As I pointed out in #15620 (comment) , it seems that the regression test is an overkill and may hit constants pool size limitation, which is a known issue and hasn't been fixed yet. Since #15620 only fix the code size limitation problem, we can simplify the test to avoid hitting constants pool size limitation. ## How was this patch tested? test only change Author: Wenchen Fan <[email protected]> Closes #16244 from cloud-fan/minor. (cherry picked from commit 9abd05b) Signed-off-by: Sean Owen <[email protected]>
## What changes were proposed in this pull request? After apache#15620 , all of the Maven-based 2.0 Jenkins jobs time out consistently. As I pointed out in apache#15620 (comment) , it seems that the regression test is an overkill and may hit constants pool size limitation, which is a known issue and hasn't been fixed yet. Since apache#15620 only fix the code size limitation problem, we can simplify the test to avoid hitting constants pool size limitation. ## How was this patch tested? test only change Author: Wenchen Fan <[email protected]> Closes apache#16244 from cloud-fan/minor.
## What changes were proposed in this pull request? After apache#15620 , all of the Maven-based 2.0 Jenkins jobs time out consistently. As I pointed out in apache#15620 (comment) , it seems that the regression test is an overkill and may hit constants pool size limitation, which is a known issue and hasn't been fixed yet. Since apache#15620 only fix the code size limitation problem, we can simplify the test to avoid hitting constants pool size limitation. ## How was this patch tested? test only change Author: Wenchen Fan <[email protected]> Closes apache#16244 from cloud-fan/minor.
## What changes were proposed in this pull request? After apache#15620 , all of the Maven-based 2.0 Jenkins jobs time out consistently. As I pointed out in apache#15620 (comment) , it seems that the regression test is an overkill and may hit constants pool size limitation, which is a known issue and hasn't been fixed yet. Since apache#15620 only fix the code size limitation problem, we can simplify the test to avoid hitting constants pool size limitation. ## How was this patch tested? test only change Author: Wenchen Fan <[email protected]> Closes apache#16244 from cloud-fan/minor.
What changes were proposed in this pull request?
After #15620 , all of the Maven-based 2.0 Jenkins jobs time out consistently. As I pointed out in #15620 (comment) , it seems that the regression test is an overkill and may hit constants pool size limitation, which is a known issue and hasn't been fixed yet.
Since #15620 only fix the code size limitation problem, we can simplify the test to avoid hitting constants pool size limitation.
How was this patch tested?
test only change