On November 12, 2019 12:54:53 AM UTC, "M. Manna" wrote:
>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
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
Currently, (in most cases) Tomcat creates an in-memory keystore and initializes
kmf as follows: KeyManagementFactory.getInstance(algo).init(keystore, kspass).
The in-memory keystore has the key, the certificate and the chain and nothing
else. This works fine in most cases but we've ran into a
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
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
> All,
>
> I'm playing with the CsrfPreventionFilter and things are working well
> in the following situations:
>
> link text
>
> and
>
>
> ...
>
>
> As long as the URL has been passed through request.encodeURL().
>
> However, this one is causing me a problem:
>
>
> ...
>
>
> This
