[SPARK-53525][CONNECT][FOLLOWUP] Spark Connect ArrowBatch Result Chunking - Scala Client #52496
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
xi-db
force-pushed
the
arrow-batch-chuking-scala-client
branch
from
ea236b1 to
0648956
Compare
vicennial
reviewed
Oct 24, 2025
Comment on lines
169
to
172
| throw new IllegalStateException( | ||
| s"Expected arrow batch to start at row offset $numRecords in results, " + | ||
| s"but received arrow batch starting at offset $expectedStartOffset.") | ||
| s"Expected chunk index ${arrowBatchChunksToAssemble.size} of the " + | ||
| s"arrow batch but got ${arrowBatch.getChunkIndex}.") | ||
| } |
Contributor
There was a problem hiding this comment.
Since these are user facing exceptions, should we be using a structured error state/code here?
Contributor
Author
There was a problem hiding this comment.
I didn't introduce new error classes, and the IllegalStateException exceptions were already in SparkResults. Yeah, switching to an structured error class can be a followup.
hvanhovell
reviewed
Oct 29, 2025
| .addAllTags(tags.get.toSeq.asJava) | ||
|
|
||
| // Add request option to allow result chunking. | ||
| val chunkingOptionsBuilder = proto.ResultChunkingOptions |
Contributor
There was a problem hiding this comment.
Do we need to set this if the chunking is disabled?
Contributor
Author
There was a problem hiding this comment.
You're right, it is not needed. I've updated the logic, so we only set chunking option when configuration.allowArrowBatchChunking is enabled.
hvanhovell
reviewed
Oct 29, 2025
| private[this] var arrowSchema: pojo.Schema = _ | ||
| private[this] var nextResultIndex: Int = 0 | ||
| private val resultMap = mutable.Map.empty[Int, (Long, Seq[ArrowMessage])] | ||
| private val arrowBatchChunksToAssemble = mutable.Buffer.empty[ByteString] |
Contributor
There was a problem hiding this comment.
Should this be local to processReponses? AFAICT it should not return unless we have a complete arrow batch.
Contributor
Author
There was a problem hiding this comment.
Good point, it's now updated to be local to processResponses.
…-scala-client # Conflicts: # sql/connect/client/jvm/src/test/scala/org/apache/spark/sql/connect/ClientE2ETestSuite.scala
Contributor
|
Merging to master/4.1. Thanks! |
asf-gitbox-commits
pushed a commit
that referenced
this pull request
Nov 3, 2025
…king - Scala Client ### What changes were proposed in this pull request? 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 #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) Signed-off-by: Herman van Hovell <[email protected]>
Member
|
@hvanhovell @xi-db, unfortunately, the daily maven test starts to fail after this patch after a closer look, I think this should be a test-only issue related to maven classpath and won't cause problems on real deployment for reference, there was a similar issue #41622 but I'm afraid the solution is not applicable for this PR. also cc @LuciferYang @dongjoon-hyun |
Contributor
@xi-db Do you have time to fix this problem? |
Member
|
Thank you for pinging me, @pan3793 and @LuciferYang . |
Member
Member
|
To @xi-db and @hvanhovell . I agree with @pan3793 's analysis that it will be only class path issues due to the difference between Maven and SBT. However, I hope this patch didn't hide any other regression for last 2 days. Inevitably, let me reverted this follow-up commit from To @pan3793 and @LuciferYang , I re-triggered |
Contributor
|
Is there any progress on this? If it's difficult to fix, can we ignore these two cases for now? |
Contributor
Author
|
Hi @LuciferYang , I'm now looking into the |
Member
|
@xi-db, this can be reproduced by |
Contributor
Author
|
Hi @pan3793 @LuciferYang , I opened a PR to fix the issue: #52941. I reproduced the issue with the commands you shared and now the Maven tests succeed with the fix. PTAL, thanks! |
Member
|
Thank you for the follow-up, @xi-db and all. |
dongjoon-hyun
pushed a commit
that referenced
this pull request
Nov 7, 2025
…ct testing ### What changes were proposed in this pull request? In this PR #52496, tests were implemented using `io.grpc.ClientInterceptor` to verify gRPC messages. However, it failed the Maven tests ([comment](#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](#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 #52941 from xi-db/arrow-batch-chunking-scala-client-fix-maven. Authored-by: Xi Lyu <[email protected]> Signed-off-by: Dongjoon Hyun <[email protected]>
xi-db
added a commit
to xi-db/spark
that referenced
this pull request
Nov 8, 2025
…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)
xi-db
added a commit
to xi-db/spark
that referenced
this pull request
Nov 8, 2025
…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)
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]>
zifeif2
pushed a commit
to zifeif2/spark
that referenced
this pull request
Nov 22, 2025
…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]>
huangxiaopingRD
pushed a commit
to huangxiaopingRD/spark
that referenced
this pull request
Nov 25, 2025
…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]>
huangxiaopingRD
pushed a commit
to huangxiaopingRD/spark
that referenced
this pull request
Nov 25, 2025
…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]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 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?
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.