Thanks Cezary. As I feared, there are many potential culprits to sniff out.
Geoff > On 16 May 2019, at 10:05 pm, Cezary Biernacki <cezary...@gmail.com> wrote: > > Obviously it would help to learn what CPU is doing. Does the application > become unstuck and start working normally after initial spike of activity? > > I have not experienced exactly the same behaviour, and I have relatively > similar technology - a Tapestry application running inside Docker on AWS > EC2, thought it is a standalone process with Dropwizard/Jetty. But years > ago I had related problems with a different WAR-based application that > crashed after not being used some time. It was caused by the "tmpwatch" > daemon on Linux deleting files in /tmp that had not been accessed after > some time. > > I recommend checking if anything in your application can be described as > "it can be removed if not used after predetermined amount of time" or "it > needs refreshing from time to time and this determined on access". > Potential culprits: > > - in-application caches, e.g. one built with Guava's Cache; > - database connections or other TCP connections where an external > service can terminate idle sessions; > - an auto-scalling mechanism; > - the application server determining that last day user sessions are > expired and killing them with a listener doing something expensive on > session's termination. > > Another option is weird garbage collection interactions, e.g. caused by > non-trivial work in the "finalize" method somewhere in the application. > > Cezary > > > On Thu, May 16, 2019 at 3:33 AM JumpStart < > geoff.callender.jumpst...@gmail.com> wrote: > >> Hi all, >> >> My app is working brilliantly under load, but after a quiet time it can be >> very slow to respond, leading our first user of the day to tap the same >> thing multiple times, and the next thing you know is CPU hits 100% and is >> stuck there, and none of those requests returns a response. Nor do any new >> requests return a response. Apache logs show that all the requests time out >> after 60 secs, unanswered, and the health checkers start messaging the >> support staff. >> >> Has anyone else experienced this kind of thing? >> >> Perhaps it’s something to do with our infrastructure? We’re running >> Tapestry from an EAR in Wildfly in Docker in an AWS EC2 instance. Also in >> that EC2 instance is Apache HTTPD in Docker. >> >> Any thoughts, please! It’s a crazy problem. >> >> Cheers, >> >> Geoff >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
