Just to give an update again: 1) We reverted the APR to 1.2.21 - but observed no difference. 2) We took 3 thread dumps over 1 min interval (without any user sessions) - All threads are tomcat's internal pool threads.
When we checked the thread details (using fasthread.io) - we didn't see any of our application stack. Since there is no user traffic, this is coming from tomcat internally. At this stage, we cannot really figure out what's the root cause. Any help is appreciated. Thanks, On Mon, 11 Nov 2019 at 20:57, M. Manna <manme...@gmail.com> wrote: > Hello All, > > Any thoughts regarding this? Slightly clueless at this point, so any > direction will be appreciated. > > We are seeing the poll taking all the CPU time. We are using > OperatingSystemMXBean.getProcessCpuLoad() and > OperatingSystemMXBean.getSystemCpuLoad() to get our metrics (then x100 to > get the pct). > > Thanks, > > > On Mon, 11 Nov 2019 at 17:46, M. Manna <manme...@gmail.com> wrote: > >> Hello, >> >> after migrating to 8.5.45, we are seeing a lot of cpu load by following >> JVM thread dump: >> >> "https-openssl-apr-0.0.0.0-8443-Poller" : 102 : RUNNABLE : >> cpu=172902703125000 : cpuLoad= 74.181015 >> >> BlockedCount:8464 BlockedTime:0 LockName:null LockOwnerID:-1 >> LockOwnerName:null >> >> WaitedCount:5397 WaitedTime:0 InNative:false IsSuspended:false at >> org.apache.tomcat.jni.Poll.poll(Poll.java:-2) >> >> at >> org.apache.tomcat.util.net.AprEndpoint$Poller.run(AprEndpoint.java:1547) >> >> at java.lang.Thread.run(Thread.java:748) >> >> >> These are coming after 2-3 successful jvm dump. Is this something >> familiar to anybody? >> >> Thanks, >> >
