[
https://issues.apache.org/jira/browse/FLINK-25398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17463067#comment-17463067
]
Junfan Zhang commented on FLINK-25398:
--------------------------------------
[~xtsong] Thanks for your quick reply
>From my perspective, this feature makes sense. Usually we use thread dump in
>runtime ui to debug the Flink job and analyze which calling the job stucked.
>However due to stacktrace frame depth limitation, I have to login to
>nodemanager to check this flink thread info. It's a terriable experience.
Hence when debugging the problems, i think the cost of dumping all complete
stack is deserved.
Do we need to introduce extra user config to enable stack depth limit? Maybe it
should be determinzed by user?
> Show complete stacktrace when requesting thread dump
> ----------------------------------------------------
>
> Key: FLINK-25398
> URL: https://issues.apache.org/jira/browse/FLINK-25398
> Project: Flink
> Issue Type: Improvement
> Reporter: Junfan Zhang
> Priority: Major
> Labels: pull-request-available
> Attachments: stacktrace.png
>
>
> h2. Why
> Now the stacktrace is not complete when clicking the task executor's
> threaddump in runtime webui. Hence it's hard to the initial calling
> according to the stacktrace.
> Now the thread stacktrace is limited to 8, refer to openjdk:
> [https://github.com/openjdk/jdk/blob/master/src/java.management/share/classes/java/lang/management/ThreadInfo.java#L597]
>
> h2. Solution
> Using the custom {{stringify}} method to return stacktrace instead of using
> {{ThreadInfo.toString}} directly
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
