[
https://issues.apache.org/jira/browse/SPARK-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15427687#comment-15427687
]
Felix Cheung commented on SPARK-16581:
--------------------------------------
I think JVM<->R is closely related to RBackend?
Because we are not trying to build a library to generically work with JVM from
R (like py4j) but only the JVM that Spark is running, via custom socket
protocol; it might come a time we want to operate from a R shell while working
with multiple JVM backends (or remote backends), or want to have more control
over recycling the backend process not completely dissimilar to cleanup.jobj,
etc.
In addition to connect to a remote JVM, we might want to expose JVM side
RBackend API to allow re-using an existing Spark JVM process (several Spark
JIRAs in the past) for cases with Spark Job Server (persisted spark session),
Apache Toree (incubating) / Livy (cross-languages support) (eg.
https://issues.cloudera.org/projects/LIVY/issues/LIVY-194)
Possibly some of these could change how callJMethod/invokeJava works, what
parameters are required and so on.
Of course, all of these could be very far off :)
> Making JVM backend calling functions public
> -------------------------------------------
>
> Key: SPARK-16581
> URL: https://issues.apache.org/jira/browse/SPARK-16581
> Project: Spark
> Issue Type: Sub-task
> Components: SparkR
> Reporter: Shivaram Venkataraman
>
> As described in the design doc in SPARK-15799, to help packages that need to
> call into the JVM, it will be good to expose some of the R -> JVM functions
> we have.
> As a part of this we could also rename, reformat the functions to make them
> more user friendly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
