[ https://issues.apache.org/jira/browse/SPARK-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14341625#comment-14341625 ]
Sean Owen commented on SPARK-6069: ---------------------------------- No, I am not suggesting that {{--conf spark.executor.extraClassPath}} is a right way to do this, but {{userClassPathFirst}} may be. There is no class conflict problem, but there is definitely a classloader visibility and thus ordering problem. It's worth a try if you have a second, since I would think this is the right way to address this and really any of this type of issue. It remains to be seen though. > 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