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 > >
