[SPARK-53525][CONNECT][FOLLOWUP][4.1] Spark Connect ArrowBatch Result Chunking - Scala Client #52953
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…king - Scala Client ### What changes were proposed in this pull request? In the previous PR apache#52271 of Spark Connect ArrowBatch Result Chunking, both Server-side and PySpark client changes were implemented. In this PR, the corresponding Scala client changes are implemented, so large Arrow rows are now supported on the Scala client as well. To reproduce the existing issue we are solving here, run this code on Spark Connect Scala client: ``` val res = spark.sql("select repeat('a', 1024*1024*300)").collect() println(res(0).getString(0).length) ``` It fails with `RESOURCE_EXHAUSTED` error with message `gRPC message exceeds maximum size 134217728: 314573320`, because the server is trying to send an ExecutePlanResponse of ~300MB to the client. With the improvement introduced by the PR, the above code runs successfully and prints the expected result. ### Why are the changes needed? It improves Spark Connect stability when returning large rows. ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? New tests. ### Was this patch authored or co-authored using generative AI tooling? No. Closes apache#52496 from xi-db/arrow-batch-chuking-scala-client. Authored-by: Xi Lyu <[email protected]> Signed-off-by: Herman van Hovell <[email protected]> (cherry picked from commit daa83fc)
…ct testing ### What changes were proposed in this pull request? In this PR apache#52496, tests were implemented using `io.grpc.ClientInterceptor` to verify gRPC messages. However, it failed the Maven tests ([comment](apache#52496 (comment))) because the related gRPC classes are missing in the testing SparkConnectService in Maven tests. In this PR, gRPC classes for testing purposes are added as artifacts like other existing classes from `scalatest` and `spark-catalyst` to also allow io.grpc classes in tests. ### Why are the changes needed? To fix the broken daily Maven tests ([comment](apache#52496 (comment))). ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? Maven tests with following commands passed. ``` $ build/mvn -Phive clean install -DskipTests $ build/mvn -Phive -pl sql/connect/client/jvm test -Dtest=none -DwildcardSuites=org.apache.spark.sql.connect.ClientE2ETestSuite ``` ### Was this patch authored or co-authored using generative AI tooling? No. Closes apache#52941 from xi-db/arrow-batch-chunking-scala-client-fix-maven. Authored-by: Xi Lyu <[email protected]> Signed-off-by: Dongjoon Hyun <[email protected]> (cherry picked from commit 1f7bbeb)
Contributor
Author
|
Hi @dongjoon-hyun , here's the backporting PR on |
dongjoon-hyun
approved these changes
Nov 8, 2025
Member
dongjoon-hyun
left a comment
dongjoon-hyun
left a comment
There was a problem hiding this comment.
+1, LGTM. Thank you, @xi-db .
Merged to branch-4.1.
dongjoon-hyun
pushed a commit
that referenced
this pull request
Nov 8, 2025
… Chunking - Scala Client ### What changes were proposed in this pull request? (This PR is a backporting PR containing #52496 and the test fix #52941.) In the previous PR #52271 of Spark Connect ArrowBatch Result Chunking, both Server-side and PySpark client changes were implemented. In this PR, the corresponding Scala client changes are implemented, so large Arrow rows are now supported on the Scala client as well. To reproduce the existing issue we are solving here, run this code on Spark Connect Scala client: ``` val res = spark.sql("select repeat('a', 1024*1024*300)").collect() println(res(0).getString(0).length) ``` It fails with `RESOURCE_EXHAUSTED` error with message `gRPC message exceeds maximum size 134217728: 314573320`, because the server is trying to send an ExecutePlanResponse of ~300MB to the client. With the improvement introduced by the PR, the above code runs successfully and prints the expected result. ### Why are the changes needed? It improves Spark Connect stability when returning large rows. ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? New tests. ### Was this patch authored or co-authored using generative AI tooling? No. Closes #52953 from xi-db/[email protected]. Authored-by: Xi Lyu <[email protected]> Signed-off-by: Dongjoon Hyun <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
(This PR is a backporting PR containing #52496 and the test fix #52941.)
In the previous PR #52271 of Spark Connect ArrowBatch Result Chunking, both Server-side and PySpark client changes were implemented.
In this PR, the corresponding Scala client changes are implemented, so large Arrow rows are now supported on the Scala client as well.
To reproduce the existing issue we are solving here, run this code on Spark Connect Scala client:
It fails with
RESOURCE_EXHAUSTEDerror with messagegRPC message exceeds maximum size 134217728: 314573320, because the server is trying to send an ExecutePlanResponse of ~300MB to the client.With the improvement introduced by the PR, the above code runs successfully and prints the expected result.
Why are the changes needed?
It improves Spark Connect stability when returning large rows.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
New tests.
Was this patch authored or co-authored using generative AI tooling?
No.