spark-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Rosen (JIRA)" <>
Subject [jira] [Commented] (SPARK-4080) "IOException: unexpected exception type" while deserializing tasks
Date Sat, 01 Nov 2014 07:49:33 GMT


Josh Rosen commented on SPARK-4080:

Spark does not currently support multiple concurrently-running SparkContexts in the same JVM
(see SPARK-2243).  In a nutshell, there are a few components that have global registries (e.g.
broadcast variables, accumulators, etc.) or are (effectively) global objects (SparkEnv), so
having multiple active SparkContexts may cause unexpected behavior.  We do not test Spark
with multiple concurrently-running SparkContexts in a single JVM, so I'm not sure what happens
when you do that; the behavior is effectively undefined.

We should display a loud warning / error when attempting to initialize a SparkContext when
another one is running and hasn't been {{stop()}}'d.  PySpark already does this, but the Scala
API should do this as well, so I've opened SPARK-4180 to add this error-checking.

> "IOException: unexpected exception type" while deserializing tasks
> ------------------------------------------------------------------
>                 Key: SPARK-4080
>                 URL:
>             Project: Spark
>          Issue Type: Bug
>          Components: Spark Core
>    Affects Versions: 1.1.0, 1.2.0
>            Reporter: Josh Rosen
>            Assignee: Josh Rosen
>            Priority: Critical
>             Fix For: 1.1.1, 1.2.0
> When deserializing tasks on executors, we sometimes see {{IOException: unexpected exception
> {code}
> unexpected exception type
>         org.apache.spark.serializer.JavaDeserializationStream.readObject(JavaSerializer.scala:62)
>         org.apache.spark.serializer.JavaSerializerInstance.deserialize(JavaSerializer.scala:87)
>         org.apache.spark.executor.Executor$
>         java.util.concurrent.ThreadPoolExecutor.runWorker(
>         java.util.concurrent.ThreadPoolExecutor$
> {code}
> Here are some occurrences of this bug reported on the mailing list and GitHub:
> -
> -
> -
> -
> This is probably caused by throwing exceptions other than IOException from our custom
{{readExternal}} methods (see
 [~davies] spotted an instance of this in TorrentBroadcast, where a failed {{require}} throws
a different exception, but this issue has been reported in Spark 1.1.0 as well.  To fix this,
I'm going to add try-catch blocks around all of our {{readExternal}} and {{writeExternal}}
methods to re-throw caught exceptions as IOException.
> This fix should allow us to determine the actual exceptions that are causing deserialization

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message