[
https://issues.apache.org/jira/browse/FLINK-34251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mingliang Liu updated FLINK-34251:
----------------------------------
Description:
Currently the ClosureCleaner throws exception if {{checkSerializable}} is
enabled while some object is non-serializable. It includes the non-serializable
(nested) object in the exception in the exception message.
However, when the user job program gets more complex pulling multiple operators
each of which pulls multiple 3rd party libraries, it is unclear how the
non-serializable object is referenced as some of those objects could be nested
in multiple levels. For example, following exception is not straightforward
where to check:
{code:java}
org.apache.flink.api.common.InvalidProgramException: java.lang.Object@528c868
is not serializable.
{code}
It would be nice to include the reference stack in the exception message, such
as:
{code:java}
org.apache.flink.api.common.InvalidProgramException: java.lang.Object@72437d8d
is not serializable. Referenced via [class com.mycompany.myapp.ComplexMap,
class com.mycompany.myapp.LocalMap, class com.yourcompany.yourapp.YourPojo,
class com.hercompany.herapp.Random, class java.lang.Object] ...
{code}
was:
Currently the ClosureCleaner throws exception if \{{checkSerializable} is
enabled while some object is non-serializable. It includes the non-serializable
(nested) object in the exception in the exception message.
However, when the user job program gets more complex pulling multiple operators
each of which pulls multiple 3rd party libraries, it is unclear how the
non-serializable object is referenced as some of those objects could be nested
in multiple levels. For example, following exception is not straightforward
where to check:
{code:java}
org.apache.flink.api.common.InvalidProgramException: java.lang.Object@528c868
is not serializable.
{code}
It would be nice to include the reference stack in the exception message, such
as:
{code:java}
org.apache.flink.api.common.InvalidProgramException: java.lang.Object@72437d8d
is not serializable. Referenced via [class com.mycompany.myapp.ComplexMap,
class com.mycompany.myapp.LocalMap, class com.yourcompany.yourapp.YourPojo,
class com.hercompany.herapp.Random, class java.lang.Object] ...
{code}
> ClosureCleaner to include reference classes for non-serialization exception
> ---------------------------------------------------------------------------
>
> Key: FLINK-34251
> URL: https://issues.apache.org/jira/browse/FLINK-34251
> Project: Flink
> Issue Type: Improvement
> Components: API / Core
> Affects Versions: 2.0.0, 1.18.2, 1.19.4
> Reporter: Mingliang Liu
> Priority: Minor
> Labels: pull-request-available
>
> Currently the ClosureCleaner throws exception if {{checkSerializable}} is
> enabled while some object is non-serializable. It includes the
> non-serializable (nested) object in the exception in the exception message.
> However, when the user job program gets more complex pulling multiple
> operators each of which pulls multiple 3rd party libraries, it is unclear how
> the non-serializable object is referenced as some of those objects could be
> nested in multiple levels. For example, following exception is not
> straightforward where to check:
> {code:java}
> org.apache.flink.api.common.InvalidProgramException: java.lang.Object@528c868
> is not serializable.
> {code}
> It would be nice to include the reference stack in the exception message,
> such as:
> {code:java}
> org.apache.flink.api.common.InvalidProgramException:
> java.lang.Object@72437d8d is not serializable. Referenced via [class
> com.mycompany.myapp.ComplexMap, class com.mycompany.myapp.LocalMap, class
> com.yourcompany.yourapp.YourPojo, class com.hercompany.herapp.Random, class
> java.lang.Object] ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
