-
Notifications
You must be signed in to change notification settings - Fork 28.2k
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
[SPARK-34125][CORE][2.4] Make EventLoggingListener.codecMap thread-safe #31194
Conversation
ok to test |
Could we please elaborate more on the impact of the issue in |
Test build #134104 has finished for PR 31194 at commit
|
Test build #134117 has started for PR 31194 at commit |
Kubernetes integration test starting |
Kubernetes integration test status success |
Does this not affect master / 3.x? |
Yes, we changed it already in Spark 3.0, but as a part of commit and we haven't realized it should be fixed in 2.4.x as well. |
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.
+1, LGTM. Thank you, @cxzl25 and all.
retest this, please |
Just triggered Jenkins/GA. Once one of them passes I'll merge this. |
Kubernetes integration test starting |
Kubernetes integration test status failure |
Test build #134132 has finished for PR 31194 at commit
|
FYI, the first commit already passed with Jenkins here. And, the second commit is an empty commit to retriever Jenkins. |
Test build #134140 has finished for PR 31194 at commit
|
Test passed. Merging. |
### What changes were proposed in this pull request? `EventLoggingListener.codecMap` change `mutable.HashMap` to `ConcurrentHashMap` ### Why are the changes needed? 2.x version of history server `EventLoggingListener.codecMap` is of type mutable.HashMap, which is not thread safe. This will cause the history server to suddenly get stuck and not work. The 3.x version was changed to `EventLogFileReader.codecMap` to `ConcurrentHashMap` type, so there is no such problem.(SPARK-28869) Multiple threads call `openEventLog`, `codecMap` is updated by multiple threads, `mutable.HashMap` may fall into an infinite loop during `resize`, resulting in history server not working. scala/bug#10436 PID 117049 0x1c939 ![image](https://user-images.githubusercontent.com/3898450/104753904-9239c280-5793-11eb-8a2d-89324ccfb92c.png) ![image](https://user-images.githubusercontent.com/3898450/104753921-9534b300-5793-11eb-99e6-51ac66051d2a.png) ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? exist ut Closes #31194 from cxzl25/SPARK-34125. Authored-by: sychen <sychen@ctrip.com> Signed-off-by: Jungtaek Lim <kabhwan.opensource@gmail.com>
Thanks @cxzl25 for the contribution! Merged to branch-2.4. |
Thank you all! |
What changes were proposed in this pull request?
EventLoggingListener.codecMap
changemutable.HashMap
toConcurrentHashMap
Why are the changes needed?
2.x version of history server
EventLoggingListener.codecMap
is of type mutable.HashMap, which is not thread safe.This will cause the history server to suddenly get stuck and not work.
The 3.x version was changed to
EventLogFileReader.codecMap
toConcurrentHashMap
type, so there is no such problem.(SPARK-28869)Multiple threads call
openEventLog
,codecMap
is updated by multiple threads,mutable.HashMap
may fall into an infinite loop duringresize
, resulting in history server not working.scala/bug#10436
PID 117049 0x1c939
Does this PR introduce any user-facing change?
No
How was this patch tested?
exist ut