Github user JoshRosen commented on the pull request:
https://github.com/apache/spark/pull/3518#issuecomment-65001985
> Thus, the serialization trace tells us which specific RDD is
unserializable and this secondary output shows how it's related to the parent
RDD.
My concern was more that even if we know which RDD in the lineage is
non-serializable, a user still might be confused about _why_ it's not
serializable. For instance, maybe one of the RDDs' functions contains a chain
of non-transient references that lead to `SparkContext`, which isn't
serializable; if this reference is behind many layers of indirection, such as
through an implicit `$outer` reference that the closure cleaner can't null out,
then it might not be obvious how the reference to SparkContext was captured in
the RDD function closure.
In the original JIRA ticket, @pwendell mentioned
http://ehcache.org/xref/net/sf/ehcache/pool/sizeof/ObjectGraphWalker.html,
which is a class for walking _arbitrary_ object graphs, which suggests to me
that the original JIRA was referring to this more general "trace the object
graph before/while it's being serialized" approach. @pwendell, want to chime
in here to clarify the scope of that JIRA?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
