2015-06-30 21:06 GMT+03:00 Rich Mayfield <rich.mayfi...@veeva.com>:
> Moved from Tomcat 7.0.55 to Tomcat 8.0.23 and now see the AJP Poller
> thread churning through a lot of CPU in a pretty much quiet system.
>
> This seems like a bug.
>
> * Restarting does not resolve the issue
Is it easy to observe the issue? Does it happen soon after a restart,
or you are waiting for a long time?
> * I've seen some mention of bumping up the memory. Doubling the max
> heap (-Xmx from 506m to 1012m) does not help. This is a relatively
> small service that is essentially idle - or at least it would be with
> the exception of this Poller thread.
>
> The connector configuration is unchanged.
>
> <Connector port="28080" protocol="AJP/1.3"
1. Note that the above value of "protocol" means auto-selecting
between APR and BIO implementations.
>From thread name (below) it selected APR implementation provided by
Tomcat-Native library.
You may try choosing another implementation of the protocol.
Version of Tomcat-Native = ? (It is logged when Tomcat starts)
> secure="true"
> scheme="https"
> connectionTimeout="20000"
> packetSize="20000"
> maxThreads="1024"
> URIEncoding="UTF-8"
> redirectPort="443"
> useSendfile="false"
> compression="force"
>
> compressableMimeTypes="text/html,text/xml,text/plain,text/javascript,text/css,application/json,application/xml"
> />
>
> The thread consuming all the CPU
2. How do you know that *this* thread consumes the cpu?
>From the stack trace it seems rather idle.
Does its state (stack trace) change over time?
Otherwise, this looks like a bug.
> "ajp-apr-28080-Poller" #62 daemon prio=5 os_prio=0
> tid=0x00002ba40293e000 nid=0x407d waiting on condition
> [0x00002ba3fc200000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000eaf94570> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at
> java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at
> java.util.concurrent.LinkedBlockingQueue.signalNotEmpty(LinkedBlockingQueue.java:172)
> at
> java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:430)
> at org.apache.tomcat.util.threads.TaskQueue.offer(TaskQueue.java:74)
> at org.apache.tomcat.util.threads.TaskQueue.offer(TaskQueue.java:31)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1361)
> at
> org.apache.tomcat.util.threads.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:161)
> at
> org.apache.tomcat.util.threads.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:141)
> at
> org.apache.tomcat.util.net.AprEndpoint.processSocket(AprEndpoint.java:896)
> at
> org.apache.tomcat.util.net.AprEndpoint$Poller.run(AprEndpoint.java:1883)
> at java.lang.Thread.run(Thread.java:745)
>
>
> # rpm -qa | grep apr
> apr-1.5.1-1
> apr-util-1.5.3-1
>
> # rpm -qa | grep http
> httpd-2.2.27-1
>
> Server version: Apache Tomcat/8.0.23
> Server built: May 19 2015 14:58:38 UTC
> Server number: 8.0.23.0
> OS Name: Linux
> OS Version: 2.6.18-371.el5
> Architecture: amd64
> JVM Version: 1.8.0_40-b25
> JVM Vendor: Oracle Corporation
>
3. Tomcat 8.0.24 has been released several days ago.
Its connector ("Coyote") section of changelog does not mention any
similar errors, although there were several changes related to
APR/native.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
