You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@spark.apache.org by "Rares Mirica (JIRA)" <ji...@apache.org> on 2017/05/30 08:18:04 UTC
[jira] [Created] (SPARK-20920) ForkJoinPool pools are leaked when
writing hive tables with many partitions
Rares Mirica created SPARK-20920:
------------------------------------
Summary: ForkJoinPool pools are leaked when writing hive tables with many partitions
Key: SPARK-20920
URL: https://issues.apache.org/jira/browse/SPARK-20920
Project: Spark
Issue Type: Bug
Components: SQL
Affects Versions: 2.1.1
Reporter: Rares Mirica
This bug is loosely related to SPARK-17396
In this case it happens when writing to a hive table with many, many, partitions (my table is partitioned by hour and stores data it gets from kafka in a spark streaming application):
df.repartition()
.write
.format("orc")
.option("path", s"$tablesStoragePath/$tableName")
.mode(SaveMode.Append)
.partitionBy("dt", "hh")
.saveAsTable(tableName)
As this table grows beyond a certain size, ForkJoinPool pools start leaking. Upon examination (with a debugger) I found that the caller is AlterTableRecoverPartitionsCommand and the problem happens when `evalTaskSupport` is used (line 555). I have tried setting a very large threshold via `spark.rdd.parallelListingThreshold` and the problem went away.
My assumption is that the problem happens in this case and not in the one in SPARK-17396 due to the fact that AlterTableRecoverPartitionsCommand is a case class while UnionRDD is an object so multiple instances are not possible, therefore no leak.
Regards,
Rares
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org