-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-32124][CORE][FOLLOW-UP] Use the invalid value Int.MinValue to fill the map index when the event logs from the old Spark version #28965
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
|
Test build #124760 has finished for PR 28965 at commit
|
| // Note, we use the invalid value -2 here to fill the map index for backward | ||
| // compatibility. Otherwise, the fetch failed event will be dropped when the history | ||
| // server loads the event log written by the Spark version before 3.0. | ||
| -2 |
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.
Any special reasons using -2 instead of -1? BTW, I'm unsure whether this filed will be displayed in UI, if so, we better show Unknown for invalid value in UI.
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.
Yeah once we provide it with magic number to mark INVALID/UNKNOWN, there should be relevant code change to handle INVALID/UNKNOWN value. Looks like the code change doesn't address it, which makes me unsure how it will be represented on the UI.
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.
@HeartSaVioR I think it is represented as error string in FetchFailed.toErrorString. So we just need to make sure the default unknown value is consistent in the code here and FetchFailed.toErrorString. Personally I prefer Int.MinValue since -1 can't be used here.
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.
Thanks Gengliang for confirming!
Any special reasons using -2 instead of -1?
mapIndex = -1 has been used in MetadataFetchFailedException.
Yep, I think Int.MinValue is a better choice.
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.
Thanks for the info! If the value is only leveraged via FetchFailed.toErrorString, what we may want to do (and proposed in previous comment) is projecting the magic number to the specific string so that it can be determined easily. +1 to Int.MinValue.
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.
And I'm seeing it's done. Thanks for the quick address!
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.
Yep, already addressed in 9dfa5c0
|
Test build #124884 has finished for PR 28965 at commit
|
|
Hi, @HeartSaVioR . Could you finalize this as an Apache Spark committer? :) |
|
@HeartSaVioR Congratulations! |
HeartSaVioR
left a comment
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.
LGTM pending Jenkins
|
retest this, please |
|
Btw thanks @dongjoon-hyun and @gengliangwang ! I thought it's probably better to take committer's work after official announcement, but this looks to be simple and good example to try out before dealing with larger PR. Thanks again for the guidance! |
|
Ya. That's also reasonable. Usually, the annoucement gets some delays because the invitations go out to multiple persons at the same season. You don't need to be blocked. ;) You've been waiting so long. Please do what you want in your way. |
|
Jenkins doesn't seem to pick this up by request ;( Mentioned the behavior in the dev@ list. |
|
retest this please |
|
Wow, Congratulations @HeartSaVioR! Well deserved! |
|
Test build #124936 has finished for PR 28965 at commit
|
|
Retest this please. |
|
Test build #124960 has finished for PR 28965 at commit
|
|
retest this, please |
|
Test build #124972 has finished for PR 28965 at commit
|
|
retest this, please |
|
Test build #125058 has finished for PR 28965 at commit
|
|
retest this, please |
|
Test build #125089 has finished for PR 28965 at commit
|
|
retest this, please |
|
Test build #125122 has finished for PR 28965 at commit
|
|
retest this, please |
|
Test build #125171 has finished for PR 28965 at commit
|
|
retest this please |
|
Test build #125190 has finished for PR 28965 at commit
|
|
retest this please |
|
Test build #125216 has finished for PR 28965 at commit
|
|
retest this please |
|
Test build #125248 has finished for PR 28965 at commit
|
…fill the map index when the event logs from the old Spark version ### What changes were proposed in this pull request? Use the invalid value Int.MinValue to fill the map index when the event logs from the old Spark version. ### Why are the changes needed? Follow up PR for #28941. ### Does this PR introduce _any_ user-facing change? When we use the Spark version 3.0 history server reading the event log written by the old Spark version, we use the invalid value -2 to fill the map index. ### How was this patch tested? Existing UT. Closes #28965 from xuanyuanking/follow-up. Authored-by: Yuanjian Li <[email protected]> Signed-off-by: Jungtaek Lim (HeartSaVioR) <[email protected]> (cherry picked from commit 3659611) Signed-off-by: Jungtaek Lim (HeartSaVioR) <[email protected]>
|
Thanks! Merged to master and branch-3.0. |
|
The very first commit merged by @HeartSaVioR! |
What changes were proposed in this pull request?
Use the invalid value Int.MinValue to fill the map index when the event logs from the old Spark version.
Why are the changes needed?
Follow up PR for #28941.
Does this PR introduce any user-facing change?
When we use the Spark version 3.0 history server reading the event log written by the old Spark version, we use the invalid value -2 to fill the map index.
How was this patch tested?
Existing UT.