[
https://issues.apache.org/jira/browse/FLINK-25970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17527838#comment-17527838
]
Xintong Song commented on FLINK-25970:
--------------------------------------
Hi [~Wencong Liu],
I'm not entirely sure whether I have understood your questions properly. Let me
provide a bit more backgrounds. Hopefully that helps you understand the issue.
The purpose of {{SerializedThrowable}}, as you may find in its JavaDoc, is to
deal with serialization of user-defined exceptions. E.g., when a task fails on
a TaskManager, it needs to report the failure cause (which is a Throwable) to
the JobManager. In order to be sent over the network connection, the Throwable
needs to be serialized on the sender (TM) side, and then deserialized on the
receiver (JM) side. If the Throwable is a user-defined class (e.g., thrown from
a UDF), the receiver side may not be able to recognize and deserialize that
class. This is way we need {{SerializedThrowable}}, to make sure the class can
be deserialized while preserving important information of the original
Throwable.
In my previously described example, a {{ConcurrentModificationException}}
occurred on the TM side, but what we seen in the JobManager logs and WebUI is a
{{SerializedThrowable}}, while neither its message (which is empty) nor its
stack provides valuable information as the class
{{ConcurrentModificationException}} does. That's why I'm proposing to make
{{SerializedThrowable}} also preserve the class name of the original Throwable.
> SerializedThrowable should record type of the original throwable.
> -----------------------------------------------------------------
>
> Key: FLINK-25970
> URL: https://issues.apache.org/jira/browse/FLINK-25970
> Project: Flink
> Issue Type: Improvement
> Components: API / Core
> Affects Versions: 1.14.3
> Reporter: Xintong Song
> Priority: Minor
> Labels: starter
>
> Currently, only the message and stack of the original throwable is preserved
> in {{{}SerializedThrowable{}}}, while the type of the original throwable is
> discarded.
> Sometimes, it would be helpful if message of {{SerializedThrowable}} can also
> include the full class name of the original throwable.
> E.g., in the following stack.
> {code:java}
> Caused by: org.apache.flink.util.SerializedThrowable
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1437)
> ~[?:1.8.0_102]
> at java.util.HashMap$EntryIterator.next(HashMap.java:1471) ~[?:1.8.0_102]
> at java.util.HashMap$EntryIterator.next(HashMap.java:1469) ~[?:1.8.0_102]
> ...
> {code}
> It's not that easy to understand what is wrong from this stack. JDK does not
> provide a message for the original exception. We have to look into the JDK
> source codes to find out what's going on. Sometimes it's even more annoying
> having to look for the JDK source codes of the exactly same version in order
> to match the line numbers.
> Turns out the original exception was a {{ConcurrentModificationException}}. I
> think it would be much more straightforward if we can have a stack like the
> following.
> {code}
> Caused by: org.apache.flink.util.SerializedThrowable:
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1437)
> ~[?:1.8.0_102]
> at java.util.HashMap$EntryIterator.next(HashMap.java:1471) ~[?:1.8.0_102]
> at java.util.HashMap$EntryIterator.next(HashMap.java:1469) ~[?:1.8.0_102]
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
