-
Notifications
You must be signed in to change notification settings - Fork 316
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
Launch dotnet backend jvm bridge process ondemand #562
base: main
Are you sure you want to change the base?
Conversation
[fix] Fix broken maven link
Launch jvm bridge if needed at SparkSession starting
Fix broken maven link in window build doc
Fix broken maven link in building/ubuntu-instructions.md (dotnet#558)
MR from dotnet spark
MR from dotnet spark
Dotnetspark master
This reverts commit 70add1d.
Thanks @laneser for the PR. However, I am not fully convinced with this approach:
Is there anything we can to update the current doc to make the experience better instead of introducing another option? I am open for further discussion to make the debugging experience seamless. cc: @suhsteve |
Thanks for your information! |
I think the JVMBridgeHelper works like pyspark launch gateway method The SparkConf could not work if jvm bridge does not exists. I will try to solve the E2E test fail, hope I could figure out why the JVMBridgeHelper does not work with SparkFixture in the unit test. Also I agreed that the helper should try to find spark home if SPARK_HOME environement is not defined. Hoping the dotnet spark listed in the https://spark.apache.org/docs/latest/sql-getting-started.html#starting-point-sparksession , We could have same experience just like other spark tools. |
Though the checks have passed, but I have no idea why it was not working before... 😿 |
…ewell/spark into feature/AddJvmBridgeHelper
We are excited to review your PR.
So we can do the best job, please check:
Fixes #nnnn
in your description to cause GitHub to automatically close the issue(s) when your PR is merged.ref #539
The SparkSession builder pattern could detect the backend jvm bridge is running or not, then launch the jvm bridge process on-demand.
In old way, spark-submit launch jvm bridge, the jvm bridge launch dotnet process.
But that is inconvenient to debug.
The SparkSession builder pattern doesn't need jvm bridge launched first.
To launch a default SparkSession
And dotnet run could do the spark job.
To launch a local SparkSession
No need to setup those config at spark-submit.
But still support the old method, because we could detect if the jvm bridge is started or not.