-
Notifications
You must be signed in to change notification settings - Fork 28.3k
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-31511][SQL][2.4] Make BytesToBytesMap iterators thread-safe #29605
Conversation
### What changes were proposed in this pull request? This PR increases the thread safety of the `BytesToBytesMap`: - It makes the `iterator()` and `destructiveIterator()` methods used their own `Location` object. This used to be shared, and this was causing issues when the map was being iterated over in two threads by two different iterators. - Removes the `safeIterator()` function. This is not needed anymore. - Improves the documentation of a couple of methods w.r.t. thread-safety. ### Why are the changes needed? It is unexpected an iterator shares the object it is returning with all other iterators. This is a violation of the iterator contract, and it causes issues with iterators over a map that are consumed in different threads. ### Does this PR introduce any user-facing change? No ### How was this patch tested? Existing tests. Closes apache#28286 from hvanhovell/SPARK-31511. Authored-by: herman <herman@databricks.com> Signed-off-by: Dongjoon Hyun <dongjoon@apache.org> (cherry picked from commit cf60384)
ok to test |
Thank you so much, @cxzl25 . cc @hvanhovell and @cloud-fan |
Also, cc @ScrapCodes for Apache Spark 2.4.7 since this is a correctness fix. |
Test build #128154 has finished for PR 29605 at commit
|
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 if tests pass
Please correct, if I am wrong, currently there are no blockers for 2.4.7 release, but we are still waiting for this one to be merged. |
Test build #128180 has finished for PR 29605 at commit
|
I don't think it's a blocker. But if the RC is not started, it's probably better to wait a bit for this patch. |
Test build #128199 has finished for PR 29605 at commit
|
retest this please |
Test build #128200 has finished for PR 29605 at commit
|
jenkins is unstable now, let's wait for the github action results. |
I saw the last backport to the pr of 2.4, and the log of the github action result also reported a similar error pyspark ArrowTest. The java arrow version of the master branch is 0.15.1, and the version of the 2.4 branch is 0.10.0.
I am not sure if the incompatibility between 0.10 and 1.0.1 caused the check to fail. I see that the pyspark test on jenkins is passed. I try to submit and trigger another jenkins test. |
retest this please |
It's really weird because both Jenkins and GitHub Action are flaky irrelevantly. |
Retest this please. |
Test build #128210 has finished for PR 29605 at commit
|
Test build #128224 has finished for PR 29605 at commit
|
Test build #128227 has finished for PR 29605 at commit
|
Test build #128232 has finished for PR 29605 at commit
|
Test build #128301 has finished for PR 29605 at commit
|
Test build #128310 has finished for PR 29605 at commit
|
Test build #128317 has finished for PR 29605 at commit
|
I removed the code I changed in the commit (0e39f7a), but the jenkins and github action tests still don't pass, which is very strange. |
retest this please |
BTW, @cxzl25 you can use empty git commit to trigger test |
Test build #128336 has finished for PR 29605 at commit
|
Test build #128337 has finished for PR 29605 at commit
|
Empty commits don't trigger a github action(No test results found!), but the jenkins test is a failure. |
retest this please |
Test build #128355 has finished for PR 29605 at commit
|
@cxzl25 why does this patch become empty? You can add empty commits to trigger tests, but you can't turn the patch into empty... |
@cloud-fan |
Test build #128360 has finished for PR 29605 at commit
|
jenkins is happy finally ... Thanks, merging to 2.4! |
### What changes were proposed in this pull request? This PR increases the thread safety of the `BytesToBytesMap`: - It makes the `iterator()` and `destructiveIterator()` methods used their own `Location` object. This used to be shared, and this was causing issues when the map was being iterated over in two threads by two different iterators. - Removes the `safeIterator()` function. This is not needed anymore. - Improves the documentation of a couple of methods w.r.t. thread-safety. ### Why are the changes needed? It is unexpected an iterator shares the object it is returning with all other iterators. This is a violation of the iterator contract, and it causes issues with iterators over a map that are consumed in different threads. ### Does this PR introduce any user-facing change? No ### How was this patch tested? add ut Closes #29605 from cxzl25/SPARK-31511. Lead-authored-by: sychen <sychen@ctrip.com> Co-authored-by: herman <herman@databricks.com> Signed-off-by: Wenchen Fan <wenchen@databricks.com>
@@ -341,6 +341,45 @@ class HashedRelationSuite extends SparkFunSuite with SharedSQLContext { | |||
assert(java.util.Arrays.equals(os.toByteArray, os2.toByteArray)) | |||
} | |||
|
|||
test("SPARK-31511: Make BytesToBytesMap iterators thread-safe") { |
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.
can you open a new PR to add this test for master/3.0?
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.
ok, I submit a pull request to add test.
#29669
Thank you, @cxzl25 and @cloud-fan . |
Now, I can go ahead and tag the release. Good work. ( A long battle with CI) |
Thank you for the release preparation, @ScrapCodes . |
What changes were proposed in this pull request?
This PR increases the thread safety of the
BytesToBytesMap
:iterator()
anddestructiveIterator()
methods used their ownLocation
object. This used to be shared, and this was causing issues when the map was being iterated over in two threads by two different iterators.safeIterator()
function. This is not needed anymore.Why are the changes needed?
It is unexpected an iterator shares the object it is returning with all other iterators. This is a violation of the iterator contract, and it causes issues with iterators over a map that are consumed in different threads.
Does this PR introduce any user-facing change?
No
How was this patch tested?
add ut