[
https://issues.apache.org/jira/browse/STORM-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144458#comment-15144458
]
Abhishek Agarwal commented on STORM-1542:
-----------------------------------------
Now I can give an easy fix just to counter this specific scenario, I do not
like the whole flow involved in this debugging utility. I sent a jstack
request, then I have to go to files section to wait for jstack dump to appear
(which in itself is not intuitive). And the requests are being routed through
zookeeper, which leads to error scenarios like these.
The whole call should be inline ideally. I was thinking worker port having an
admin port on which worker jvm itself can be queried for thread stack trace.
But then for each worker, two ports would have to be configured.
Other option is to have an admin port in supervisor itself. Here supervisor can
still execute the jstack, jmap commands etc and return them in the same call.
Any thoughts/suggestions?
> Clicking jstack for a worker in UI results in endless empty jstack dumps
> ------------------------------------------------------------------------
>
> Key: STORM-1542
> URL: https://issues.apache.org/jira/browse/STORM-1542
> Project: Apache Storm
> Issue Type: Bug
> Components: storm-core
> Affects Versions: 1.0.0
> Reporter: Abhishek Agarwal
> Assignee: Abhishek Agarwal
> Priority: Critical
>
> Resolved path for jstack is
> /home/y/share/yjava_jdk/java/jstack which doesn't exist. Exit code returned
> is 127. When a request for jstack dump is made, a zookeeper entry is made for
> the action. Now supervisor keeps on reading this action, executes it and
> since exit code is non-zero, doesn't delete the node. So supervisor keeps on
> trying forever and the non-existent command results in empty file
> {noformat}
> $BINPATH/jstack $1 > "$2/${FILENAME}"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
