[
https://issues.apache.org/jira/browse/SPARK-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Owen updated SPARK-6069:
-----------------------------
Priority: Major (was: Blocker)
Fix Version/s: (was: 1.2.2)
This can be bumped up after some more diagnosis. For example I'm interested in
the effect of userClassPathFirst here.
The underlying issue, described in
http://mail-archives.apache.org/mod_mbox/spark-user/201502.mbox/%3C88740D85-11BE-4F31-95A4-F1558F6537C3%40occamsmachete.com%3E
seems to be visibility of user classes from the kryo deserializer.
I'd like to phone a friend who may have looked at things like this in the past:
[~matt.whelan] and [~grahamdennis]
Also eyeing https://issues.apache.org/jira/browse/SPARK-1863
> Deserialization Error ClassNotFound
> ------------------------------------
>
> Key: SPARK-6069
> URL: https://issues.apache.org/jira/browse/SPARK-6069
> Project: Spark
> Issue Type: Bug
> Components: Spark Core
> Affects Versions: 1.2.1
> Environment: Standalone one worker cluster on localhost, or any
> cluster
> Reporter: Pat Ferrel
>
> A class is contained in the jars passed in when creating a context. It is
> registered with kryo. The class (Guava HashBiMap) is created correctly from
> an RDD and broadcast but the deserialization fails with ClassNotFound.
> The work around is to hard code the path to the jar and make it available on
> all workers. Hard code because we are creating a library so there is no easy
> way to pass in to the app something like:
> spark.executor.extraClassPath /path/to/some.jar
--
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
