[
https://issues.apache.org/jira/browse/SPARK-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14138390#comment-14138390
]
Matei Zaharia commented on SPARK-2593:
--------------------------------------
The reason that we don't want to expose Akka classes in public APIs is that
Spark has stricter versioning guidelines than Akka:
https://cwiki.apache.org/confluence/display/SPARK/Spark+Versioning+Policy.
Basically, all of Spark 1.X is going to be backward-compatible, so that means
that we might get stuck with an old version of Akka that we have to maintain,
which won't link with user's new versions of Akka.
We can, however, provide a way to do this through reflection or *maybe* through
an API marked "@DeveloperApi" so it's not guaranteed to work across releases.
I'm also curious though, in practice, are there major problems with having 2
ActorSystems in the same app? It will create better fault isolation, and we do
use Akka in fairly heavy ways (e.g. sending large messages, configuring our own
timeouts, etc). I can see this leading to crashes that would not have happened
otherwise.
> Add ability to pass an existing Akka ActorSystem into Spark
> -----------------------------------------------------------
>
> Key: SPARK-2593
> URL: https://issues.apache.org/jira/browse/SPARK-2593
> Project: Spark
> Issue Type: Improvement
> Components: Spark Core
> Reporter: Helena Edelson
>
> As a developer I want to pass an existing ActorSystem into StreamingContext
> in load-time so that I do not have 2 actor systems running on a node in an
> Akka application.
> This would mean having spark's actor system on its own named-dispatchers as
> well as exposing the new private creation of its own actor system.
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
