Uh oh!
There was an error while loading. Please reload this page.
[SPARK-12837][SPARK-20666][CORE][FOLLOWUP] getting name should not fail if accumulator is garbage collected - #17931
[SPARK-12837][SPARK-20666][CORE][FOLLOWUP] getting name should not fail if accumulator is garbage collected#17931cloud-fan wants to merge 2 commits into
Conversation
cloud-fan
commented
May 10, 2017
cc @vanzin |
rxin
commented
May 10, 2017
What's the issue with SQL metrics? |
SparkQA
commented
May 10, 2017
Test build #76726 has started for PR 17931 at commit |
cloud-fan
commented
May 10, 2017
we will keep task context accumulators don't have this problem as we always keep the registered accumulators in DAGScheduler |
cloud-fan
commented
May 10, 2017
retest this please |
SparkQA
commented
May 10, 2017
Test build #76741 has finished for PR 17931 at commit
|
vanzin
commented
May 11, 2017
Do you have an idea of how much this undoes the benefits of SPARK-12837? You're still avoiding sending the names of internal metrics, but I don't have a feel for how many accumulators a large sql query might generate. Also, is that really necessary? The errors seen in the bug (and that I noticed in my testing) were always on the driver side. |
cloud-fan
commented
May 12, 2017
at the time we received |
vanzin
commented
May 12, 2017
I see. What about the gains from SPARK-12837? Are they still enough that the change is justified, or should we just revert it instead? |
vanzin
commented
May 12, 2017
(BTW, if keeping the code, a slightly more verbose comment in the code explaining why non-internal accumulators still need to send their names would be good.) |
I checked the SPARK-12837 again and we only lose a little from this PR. I'll add more comments. |
SparkQA
commented
May 15, 2017
Test build #76937 has finished for PR 17931 at commit
|
vanzin
commented
May 15, 2017
LGTM. |
vanzin
commented
May 15, 2017
Merging to master / 2.2. |
…il if accumulator is garbage collected ## What changes were proposed in this pull request? After #17596 , we do not send internal accumulator name to executor side anymore, and always look up the accumulator name in `AccumulatorContext`. This cause a regression if the accumulator is already garbage collected, this PR fixes this by still sending accumulator name for `SQLMetrics`. ## How was this patch tested? N/A Author: Wenchen Fan <wenchen@databricks.com> Closes#17931 from cloud-fan/bug. (cherry picked from commit e1aaab1) Signed-off-by: Marcelo Vanzin <vanzin@cloudera.com>
…il if accumulator is garbage collected ## What changes were proposed in this pull request? After apache#17596 , we do not send internal accumulator name to executor side anymore, and always look up the accumulator name in `AccumulatorContext`. This cause a regression if the accumulator is already garbage collected, this PR fixes this by still sending accumulator name for `SQLMetrics`. ## How was this patch tested? N/A Author: Wenchen Fan <wenchen@databricks.com> Closesapache#17931 from cloud-fan/bug.
…il if accumulator is garbage collected ## What changes were proposed in this pull request? After apache#17596 , we do not send internal accumulator name to executor side anymore, and always look up the accumulator name in `AccumulatorContext`. This cause a regression if the accumulator is already garbage collected, this PR fixes this by still sending accumulator name for `SQLMetrics`. ## How was this patch tested? N/A Author: Wenchen Fan <wenchen@databricks.com> Closesapache#17931 from cloud-fan/bug.
What changes were proposed in this pull request?
After #17596 , we do not send internal accumulator name to executor side anymore, and always look up the accumulator name in
AccumulatorContext.This cause a regression if the accumulator is already garbage collected, this PR fixes this by still sending accumulator name for
SQLMetrics.How was this patch tested?
N/A