Here's the stack trace dump: https://gist.github.com/jamiejackson/ca2a49d2c8afac496067
FWIW, I've been trying to come up with a reliable test case to trigger the problem, but I haven't nailed it yet. I've suspected that it's related to file (large or slow) HTTP file uploads, and that's what I was running at the time, which helps to explain the java.net.SocketInputStream.socketRead0 traces. Thanks, Jamie On Fri, Oct 9, 2015 at 7:32 AM, Jamie Jackson <jamieja...@gmail.com> wrote: > Thanks, so far, everyone. > > I do already have a JVM monitoring tool in action--FusionReactor. I'm not > very familiar with some of the other offerings, but FR has seemed > full-featured to me, so I'm going to continue with FR until I find out > if/that it's missing some key aspect. > > I managed to trigger the problem on my load test server yesterday, and > grabbed a stack trace from FR. Sometimes, the problem identified by a stack > trace is obvious (to me), but I didn't spot anything in this one, at a > glance. > > I"ll post the stack trace once I get back to work, and we can start there. > > Thanks, > Jamie > > On Thu, Oct 8, 2015 at 3:25 PM, Leon Rosenberg <rosenberg.l...@gmail.com> > wrote: > >> On Wed, Oct 7, 2015 at 11:59 PM, Aurélien Terrestris < >> aterrest...@gmail.com> >> wrote: >> >> > Hi Jamie, >> > .... >> > >> > If you enjoy live monitoring, you need to have a look on Christopher's >> > presentation ( >> > >> > >> http://events.linuxfoundation.org/sites/events/files/slides/Monitoring%20Apache%20Tomcat%20with%20JMX.pdf >> > ) who posts many answers to this mailing list. >> > >> > >> > or if you want to go deeper, try MoSKito (http://www.moskito.org) >> >> regards >> Leon >> >> >> > >> > >> > >
