Fork me on GitHub
#admin-announcements
<
2015-07-20
>
rui.yang07:07:27

hello, wonder if anyone has any experience debugging Tomcat not responding in production? what's the logic steps usually to tackle such jvm investigation? Thanks in advance.

rui.yang07:07:26

basically Tomcat has very slow response time, also saw a lot stack overflow exception in logs.

agile_geek07:07:53

@rui.yang: if possible reproduce in another environment and instrument the JVM using a profiler. I not possible to reproduce use profiler on production instance. Switch on any debug logging messages you’ve got. This looks like a logic path with a stack consuming recursive loop?

rui.yang07:07:49

@agile_geek: we are on oracle jvm 7, currently not reproducible in other env. Not sure if it will happen in future or not. Will try to setup production jvm to enable future monitoring. any recommendation for the tools to profile and monitor production jvm?

danielcompton07:07:42

@rui.yang: jvisualvm is a good start

rui.yang08:07:57

@danielcompton thanks, will check it out

tcrayford10:07:06

@rui.yang I'd also look at turning on GC logs and seeing what the garbage collector is up to

bruceadams10:07:16

@rui.yang a stack overflow is typically really bad. Do you have a stack trace of one of those? Tracking that down to a cause is worth doing.

bruceadams10:07:23

One of my favorite tools for diagnosing slow or hung JVMs in production is thread dumps. Grab a series of three (or more) thread dumps at periodic intervals (say 30 seconds apart) and look at what is happening.

agile_geek15:07:46

@bruceadams: agree about thread dumps. Used before many a time in Java apps.

roberto16:07:49

“Luc” in this thread is very rude. I’m glad he was called out for it. I wouldn’t like to see the clojure community adopting his attitude.

curtosis17:07:13

The quality of this community is 20%* of why I love/use clojure. *MSRP. Taxes, shipping, and other fees not included.

ivanreese21:07:51

@roberto: Yeah, props to @cfleming for being so level-headed about it