Uh oh!
There was an error while loading. Please reload this page.
[SPARK-23415][SQL][TEST] Make behavior of BufferHolderSparkSubmitSuite correct and stable - #20636
[SPARK-23415][SQL][TEST] Make behavior of BufferHolderSparkSubmitSuite correct and stable#20636kiszk wants to merge 14 commits into
Conversation
SparkQA
commented
Feb 19, 2018
Test build #87541 has finished for PR 20636 at commit
|
kiszk
commented
Feb 19, 2018
dongjoon-hyun
commented
Feb 19, 2018
Thank you for pining me and working on this issue, @kiszk . |
There was a problem hiding this comment.
Ping, @liufengdb and @gatorsmile .
kiszk
commented
Mar 9, 2018
ping @liufengdb and @gatorsmile |
kiszk
commented
Mar 19, 2018
ping @gatorsmile and @liufengdb |
kiszk
commented
Mar 26, 2018
ping @gatorsmile and @hvanhovell |
kiszk
commented
Apr 10, 2018
ping @hvanhovell |
kiszk
commented
Apr 10, 2018
retest this please |
There was a problem hiding this comment.
Good question. Several tests still seem to use local-cluster. Is it better to use local while it may require more memory?
There was a problem hiding this comment.
I think we support this for testing purpose since, IIRC, that's going to make separate processes for workers.
SparkQA
commented
Apr 10, 2018
Test build #89146 has finished for PR 20636 at commit
|
kiszk
commented
Apr 17, 2018
retest this please |
SparkQA
commented
Apr 17, 2018
Test build #89447 has finished for PR 20636 at commit
|
kiszk
commented
Apr 18, 2018
retest this please |
SparkQA
commented
Apr 18, 2018
Test build #89475 has finished for PR 20636 at commit
|
kiszk
commented
Apr 18, 2018
retest this please |
SparkQA
commented
Apr 18, 2018
Test build #89477 has finished for PR 20636 at commit
|
SparkQA
commented
Apr 18, 2018
Test build #89485 has finished for PR 20636 at commit
|
kiszk
commented
Apr 18, 2018
retest this please |
SparkQA
commented
Apr 18, 2018
Test build #89494 has finished for PR 20636 at commit
|
hvanhovell
commented
Apr 19, 2018
@kiszk Why do we need to allocate a large array several times? I thought the objective of this test is to check if we can safely grow to int max? I don't really see the need for resetting the array before every grow call. Am I missing something here? |
kiszk
commented
Apr 19, 2018
Ah, I see. I thought the objective is to check if we can safely allocate buffer with each size. According to my understanding, you think to reuse buffer is an intention of this test. While |
kiszk
commented
Apr 19, 2018
@hvanhovell BTW, could you favor me? At In the method Then, we execute As a result, when Should we keep this? Or, should we add check if |
SparkQA
commented
Apr 20, 2018
Test build #89653 has finished for PR 20636 at commit
|
kiszk
commented
Apr 21, 2018
@hvanhovell When I added the new check code to see whether the growth value is negative, we see the following error. Finally, How do we handle this? Should we pass |
kiszk
commented
May 2, 2018
ping @hvanhovell |
2 similar comments
kiszk
commented
May 9, 2018
ping @hvanhovell |
kiszk
commented
May 15, 2018
ping @hvanhovell |
kiszk
commented
Jun 18, 2018
cc @cloud-fan |
HyukjinKwon
commented
Jul 16, 2018
retest this please |
1 similar comment
kiszk
commented
Jul 16, 2018
retest this please |
SparkQA
commented
Jul 16, 2018
Test build #93123 has finished for PR 20636 at commit
|
kiszk
commented
Jul 17, 2018
retest this please |
SparkQA
commented
Jul 17, 2018
Test build #93147 has finished for PR 20636 at commit
|
HyukjinKwon
commented
Jul 17, 2018
retest this please |
SparkQA
commented
Jul 17, 2018
Test build #93153 has finished for PR 20636 at commit
|
kiszk
commented
Jul 17, 2018
retest this please |
SparkQA
commented
Jul 17, 2018
Test build #93158 has finished for PR 20636 at commit
|
kiszk
commented
Jul 17, 2018
cc @cloud-fan |
1 similar comment
kiszk
commented
Jul 28, 2018
cc @cloud-fan |
| holder.grow(ARRAY_MAX + 1 - holder.totalSize()) | ||
| assert(false) | ||
| } catch { | ||
| case _: UnsupportedOperationException => assert(true) |
There was a problem hiding this comment.
Fix the indents here. assert(true) is a no-op, so just omit it. assert(false) is less useful than fail(...message...), above. Let an unexpected Throwable just fly out of the method to fail it rather than swallow it. But do you really just want to use intercept here?
| "--master", "local-cluster[2,1,1024]", | ||
| "--driver-memory", "4g", | ||
| "--master", "local-cluster[1,1,7168]", | ||
| "--driver-memory", "7g", |
There was a problem hiding this comment.
Hm, just wondering if it's going to be problematic that the test now spawns a job that needs more than 7G of RAM? maybe I misunderstand.
SparkQA
commented
Aug 8, 2018
Test build #94426 has finished for PR 20636 at commit
|
SparkQA
commented
Aug 8, 2018
Test build #94434 has finished for PR 20636 at commit
|
SparkQA
commented
Aug 8, 2018
Test build #94436 has finished for PR 20636 at commit
|
kiszk
commented
Aug 9, 2018
retest this please |
SparkQA
commented
Aug 9, 2018
Test build #94463 has finished for PR 20636 at commit
|
SparkQA
commented
Aug 9, 2018
Test build #94465 has finished for PR 20636 at commit
|
kiszk
commented
Aug 9, 2018
retest this please |
SparkQA
commented
Aug 9, 2018
Test build #94472 has finished for PR 20636 at commit
|
kiszk
commented
Aug 9, 2018
retest this please |
cloud-fan
commented
Aug 9, 2018
LGTM |
SparkQA
commented
Aug 9, 2018
Test build #94477 has finished for PR 20636 at commit
|
cloud-fan
commented
Aug 9, 2018
thanks, merging to master! |
What changes were proposed in this pull request?
This PR addresses two issues in
BufferHolderSparkSubmitSuite.BufferHolderSparkSubmitSuitetried to allocate a large object several times, it actually allocated an object once and reused the object.BufferHolderSparkSubmitSuitemay fail due to timeoutTo assign a small object before allocating a large object each time solved issue 1 by avoiding reuse.
To increasing heap size from 4g to 7g solved issue 2. It can also avoid OOM after fixing issue 1.
How was this patch tested?
Updated existing
BufferHolderSparkSubmitSuite