[
https://issues.apache.org/jira/browse/STORM-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15150027#comment-15150027
]
Abhishek Agarwal commented on STORM-1542:
-----------------------------------------
[~revans2] Yes, your assumption is correct. Also we can build a command line
tool over rest API, if needed.
[~kishorvpatil] The disadvantage I see is that it is very important to clear an
action in zookeeper so that it is not executed again. However such scenarios
can be identified and fixed. My primary concern is the asynchronous nature of
call and viewing the output through a file dump. If I submit a request such as
jstack, jmap on UI, I as a user expect an immediate output on the web page
itself. If logviewer consumes these requests, it can serve the request
synchronously without storing in a file. Additionally there is no mechanism of
cleaning up file dumps and for a user it is difficult to know which dump
corresponds to his jstack request. By serving the output directly on page
solves that problem.
If multiple users are submitting heap dump requests, we can chose to do that in
different threads.
Other concerns coming out in doing it synchronously through logviewer
1. pid discovery - logviewer has access to same configuration as supervisor.
Supervisor reads worker-artifcats directory to read the pid. Logviewer can do
the same as long as it knows the worker-id
2. profiler actions - It is inherently asynchronous in nature. We can move away
from time-bound stop to manual stop. User can start the profiler and manually
stop the profiler (similar to debug/stop-debug we have for topologies).
What do you think?
> Taking 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 command on supervisor is
> /home/y/share/yjava_jdk/java/jstack which doesn't exist. command returns 127
> as exit code. When a request for jstack dump is made from UI, a zookeeper
> node is created. Now supervisor keeps on reading this node, executes jstack
> command and since exit code is non-zero, doesn't delete the node afterwards.
> Thus supervisor keeps on executing the command forever and each invocation
> creates an new empty file.
> {noformat}
> $BINPATH/jstack $1 > "$2/${FILENAME}"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
