[
https://issues.apache.org/jira/browse/FLINK-25398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17463053#comment-17463053
]
Xintong Song commented on FLINK-25398:
--------------------------------------
Hi [~zuston],
Thanks for bringing this up. However, I'm not sure removing the stack depth
limit is always an improvement for this feature. My gut feeling this will be
improving the experience in some cases where deeper stack information is
needed, at the cost of making the experience worse in many other use cases.
While providing complete information, removing the limit may also slow down
generating the thread dump, bug users with redundant information and slow down
the web ui. I think that's probably why JDK decides not to print the complete
thread stack in the first place, and I'm in favor of respecting the judgement
of the JDK team.
> 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)
