Yep, I figured that out. Now I'm just waiting for the app to freeze. Unfortunately I can't email the thread dump to myself because it's on a private network. Well I can, but I can't move it from the private network.
On Tue, Nov 17, 2015 at 1:43 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > Larry, > > On 11/17/15 10:13 AM, Cohen, Laurence wrote: > > Chris, that's what I'm planning on doing. But how do I get the pid since > > it will change each time I bounce the java process? Also, I'll have to > > figure out how to read the thread dump. > > You should be able to use "ps" and "grep" to find the process id. > > Don't bother reading the thread dump: just email it to yourself. > > -chris > > > On Mon, Nov 16, 2015 at 5:48 PM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > >> Larry, > >> > >> On 11/16/15 5:08 PM, Cohen, Laurence wrote: > >>> Thank you Christopher. I'm going to start with the thread dump since > we > >>> are using jdk and that appears very straightforward. Part of my > dilemma > >> is > >>> that the problem is occurring on a private network where I do not have > >>> access to the internet. > >> > >> You could have your 'wget' script trigger a jstack before bouncing > >> Tomcat. That way, you don't have to have quick access to the server when > >> it starts misbehaving. > >> > >>> Our public facing application with the same exact > >>> build is not experiencing this problem, so I'm wondering if this is a > >>> network issue on the private side. I'll start here though. > >> > >> It's nice that it's not the other way around. It's *usually* the other > >> way around: dev/test is juuuuust fine but prod is hosing all over the > >> place. > >> > >> -chris > >> > >>> On Mon, Nov 16, 2015 at 4:55 PM, Christopher Schultz < > >>> ch...@christopherschultz.net> wrote: > >>> > >>>> Larry, > >>>> > >>>> On 11/16/15 4:42 PM, Cohen, Laurence wrote: > >>>>> Are there any tools that come with Java that I can use to > troubleshoot > >> an > >>>>> intermittent problem we are having? The problem is that several > times > >> a > >>>>> day, our Tomcat applications will stop responding and I'll have to > >>>> restart > >>>>> them to get them working again. It's gotten to the point where I > have > >>>>> written a script which does a wget every 10 minutes against an object > >> in > >>>>> the DB, and if it fails, it will restart our apps. > >>>> > >>>> Consider using a real monitoring tool. There are some free ones > >>>> available, such as Nagios and ighinga, that aren't much more > complicated > >>>> than your wget script, except that they have alerting, history, etc. > all > >>>> built around them. They also let you sample LOTS of things. > >>>> > >>>>> I've also done some statistics gathering and imported them into a > >>>>> spreadsheet so I can see what is going on at the time the system is > >>>>> crashing. All I can see is that the Tomcat connections are spiking. > >>>> > >>>> Spiking to a particular limit? What does your connector configuration > >>>> look like? And your deployment? > >>>> > >>>>> We are running Tomcat 7.0.59 with two apps, Postgres 9.2 on the > backend > >>>>> which is not administered by us, and httpd on the front end, 2.2.15. > >> The > >>>>> httpd server and app server are RHEL6. > >>>> > >>>> Just a single Tomcat instance? That narrows things down a bit. How are > >>>> you reverse-proxying? mod_jk? mod_proxy_http? > >>>> > >>>> What does your JNDI DataSource configuration look like? > >>>> > >>>> Are you able to take a thread dump when the server seizes-up? > >>>> > >>>> > >> > http://wiki.apache.org/tomcat/HowTo#How_do_I_obtain_a_thread_dump_of_my_running_webapp_.3F > >>>> > >>>> This will tell you what the server is doing. I suspect you'll see a > >>>> bunch of threads waiting on a database connection or something like > >> that. > >>>> > >>>> -chris > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >>>> For additional commands, e-mail: users-h...@tomcat.apache.org > >>>> > >>>> > >>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- [image: www.novetta.com] Larry Cohen System Administrator 12021 Sunset Hills Road, Suite 400 Reston, VA 20190 Email lco...@novetta.com Office 703-885-1064
