Hi Martin,
In researching my jstack not working issue I too came across the make sure
you run jstack as the same user that tomcat is running as. So I did try
su'ing to my tomcat user and issuing the jstack -F -l -m <pid> command to no
avail. After I reproduce my application deadlock again this morning
(hopefully) I'll try jstack again without the -F and I'll also try the kill
-QUIT. I did not have to enable JMX on this particular tomcat instance in
order to use jvisualvm. I don't think jmx comes in to play when using
jvisualvm. I just went into our server room and pulled up a terminal window
right off the server's desktop in order to launch jvisualvm (going to hookup
cygwin/x instead shortly).
Even though jvisualvm was unable to retrieve stacktraces for the threaddumps
and pull them into it's GUI for display ("exception while walking
stacktrace") every time I issued a thread dump command through jvisualvm it
did indeed dump all my thread info + stacktraces into my tomcat logs, it
just couldn't pull it into the GUI for some reason.
Wesley: I now do think my initial kill -QUIT worked as well, I just didn't
check the right log or for some reason was expecting it to dump to the
command line rather than in my tomcat logs where it did go.
Mark: Definitely going to update those dbcp libs. First step for me is to
try and find a way to reliably reproduce hangup so I'll have a test case to
come back to in order to verify any subsequent fixes actually did the job.
Thanks for the input - Jason
On Thu, Oct 21, 2010 at 6:02 AM, Martin Kuen <martin.k...@gmail.com> wrote:
> jason,
>
> Out of personal interest I have a question about the way you use jstack. I
> came across this "jstack cannot take dump of hung process" problem before.
> I
> once witnessed the same exceptions when chasing a deadlock.
>
> This happened to me on ubuntu 10.4.0 (and 10.4.1) 64-bit using sun's jdk
> 1.6.0_21
>
> My mistake was to invoke jstack as a different user, that is, not the user
> which is running the given java application (e.g. root instead of tomcat6).
> Invoking jstack with the -F option as root showed these exceptions, whereas
> kill -QUIT didn't produce anything and jstack without -F failed as well.
>
> As a quick workaround I changed /etc/passwd to allow the user tomcat6 to
> use
> a shell. Issuing a "su tomcat6" as root I was able to get jstack (and kill
> -QUIT) working. Disclaimer: I don't know how tomcat is packaged for Red
> Hat.
>
> I tried to check this with so. who actually claimed that his jvm was hung
> when he tried to get a stack-trace. However, I was told that the problem no
> longer exists (no hung jvm anymore) and the investigation ceased.
>
> This is were you come into play :)
>
> It appears to me that "hung application" alone does not imply that "-F" is
> required. So, if my application enters a infinite loop or gets stuck in a
> deadlock my application is unresponsive and will most likely be referred to
> as "hung", but the vm is actually functioning perfectly. It's just my
> application, that, well, . . . .
>
> In my case I was able to get a stacktrace from an application which was
> stuck in a deadlock (log4j with multiple appenders, multiple threads using
> the same Logger instance) without using "-F" at all.
>
> When you use jvisualvm you most likely do so by enabling (and connecting
> through) jmx (true?). I believe it's correct to claim that this is at least
> a different way of attaching to the vm, than using jstack from the
> comandline. Could be the reason why you were "suddenly" able to get a
> thread
> dump.
>
> Could you give it a shot?
>
>
> Best Regards,
>
> Martin
>
