com.esotericsoftware.kryo.kryoexception java.util.ConcurentModificationException

最近 有網友看個人「整合Kafka到Spark Streaming——代碼示例和挑戰」文章，
講 kafka對象 放到 pool 並經過broadcast廣播出去：

而後 在開發測試階段 報錯以下：

而後就找我，說「代碼都跟你的差很少呀，爲何就報這個錯呢？」
其實 對於廣播操做，spark 確定要序列號的，還有儘可能不要把大對象廣播出去，
後來 把代碼要過來看了下，發現 createKafkaProducerPool這個方法 ，單首創建了一個類，同時這個類 extends Serializable ，我當時的感受就是，若是createKafkaProducerPool方法 ，寫在main方法 or Driver端 應該就確定不會有這個問題，我也建議這樣搞的，還有 我懷疑 集羣是啓用了Kryo序列號方式，而createKafkaProducerPool方法所在類居然 extends Serializable ，不解

important：

The closures (anon function going inside RDD.map(…)) are serialized by Spark before distributing them. Hadoop does not have this problem because it binary-serializes the whole .jar and copies it over the network. Spark uses JavaSerialization by default, but it is very slow compared to, say, Kryo. So we use Kryo to do that by using a wrapper (Spark doesn’t support kryo-serde for closures, not yet).

And uptill now the org.dbpedia.extraction.spark.serializeKryoSerializationWrapper class has been working perfectly. Some freak extractors seem to fail though.

根據這個錯誤檢索的文章

1. https://github.com/dbpedia/distributed-extraction-framework/issues/9
2. http://stackoverflow.com/questions/27277015/sparkcontext-broadcast-jedispool-not-work
3. http://apache-spark-user-list.1001560.n3.nabble.com/why-does-quot-com-esotericsoftware-kryo-KryoException-java-u-til-ConcurrentModificationException-quo-tc23067.html

若是你們有遇到這樣問題或者什麼好想法，請回復，THX ~

版權聲明：本文爲博主原創文章，未經博主容許不得轉載。