On 12/01/2017 21:09, Enrico Olivelli wrote: > Thank you Chris > > Il gio 12 gen 2017, 18:04 Christopher Schultz <ch...@christopherschultz.net> > ha scritto: > > Enrico, > > On 1/12/17 8:53 AM, Enrico Olivelli wrote: >>>> I'm upgrading from Tomcat 8.0.33. I see that after a period of work >>>> requests remains "pending", for instance I get all clients >>>> remaining waiting for a response (parsing HTTP Response header) and >>>> no active thread on my Tomcat. >>>> >>>> This happens in my QA environment where I start several >>>> WebDriver/Unit tests againts my web application. I have many cases, >>>> the most simple I this is the following: >>>> >>>> on the client side (a JAX-WS client): >>>> >>>> "main" #1 prio=5 os_prio=0 tid=0x00007f7cf0009000 nid=0x7ddc >>>> runnable [0x00007f7cf6e3f000] >>>> >>>> java.lang.Thread.State: RUNNABLE >>>> >>>> at java.net.SocketInputStream.socketRead0(Native Method) >>>> >>>> at >>>> java.net.SocketInputStream.socketRead(SocketInputStream.java:116) >>>> >>>> at java.net.SocketInputStream.read(SocketInputStream.java:170) >>>> >>>> at java.net.SocketInputStream.read(SocketInputStream.java:141) >>>> >>>> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) >>>> >>>> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) >>>> >>>> at java.io.BufferedInputStream.read(BufferedInputStream.java:345) >>>> >>>> - locked <0x00000000fd159a18> (a java.io.BufferedInputStream) >>>> >>>> at >>>> sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:704) > > Okay, client is waiting. > > >> From server side application logs I see that the webapp has processed the >> request. In this case I am using Metro JAX-WS. >> It seems that the reponse is waiting in some buffer. >> Is there any way to inspect tomcat buffers? Network buffers? I am using >> linux. > >> The strange thing is that with Tomcat 8.0.33 there is no problem. >> The same problem happens even with other servlets of different frameworks >> and other webapps. > >> On 8.0.x I was using Nio connector, on 8.5 I am using Nio2. >> The problem is both on http and jsse https.
Try NIO. Mark > >> Is any new relevant default value changed from 8.0 and 8.5? I can't find >> any idea on changelogs or documentation > > > > > >>>> in the server side: Full thread dump Java HotSpot(TM) 64-Bit Server >>>> VM (25.92-b14 mixed mode): >>>> >>>> >>>> "anInnocuousThread" #861 daemon prio=5 os_prio=0 >>>> tid=0x00007ff23c0de800 nid=0xdb26 runnable [0x00007ff1ad379000] >>>> java.lang.Thread.State: RUNNABLE at >>>> sun.nio.ch.EPoll.epollWait(Native Method) at >>>> sun.nio.ch.EPollPort$EventHandlerTask.poll(EPollPort.java:194) at >>>> sun.nio.ch.EPollPort$EventHandlerTask.run(EPollPort.java:268) at >>>> java.lang.Thread.run(Thread.java:745) at >>>> sun.misc.InnocuousThread.run(InnocuousThread.java:74) >>>> >>>> (lots of this kind....) (HTTPS Connector I think) > > Without the rest of the stack trace, it's hard to tell if those are okay > > >> I have cut all the other threads which had the same stacktrace. >> I have stripped out GC threads, JMX... >> My application is not present in any thread but I have several clients >> stuck at waiting for a response. > >> As soon as I can I will attach the full dump > >> Thank you very much >> I appreciate your help > >> Enrico > >> . > >>>> "https-jsse-nio2-10.168.10.55-8443-exec-130" #572 daemon prio=5 >>>> os_prio=0 tid=0x00007ff23c0a0000 nid=0xd4a2 waiting on condition >>>> [0x00007ff1b2bbf000] java.lang.Thread.State: WAITING (parking) at >>>> sun.misc.Unsafe.park(Native Method) - parking to wait for >>>> <0x0000000080f1d420> (a >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > > These >>>> > are request-processing threads, waiting for work. They are idle. > >>>> (lots of this kind....) (HTTP Connector I think) >>>> >>>> "http-nio2-10.168.10.55-8080-exec-21" #281 daemon prio=5 os_prio=0 >>>> tid=0x00007ff2340e7000 nid=0xd262 waiting on condition >>>> [0x00007ff1af995000] java.lang.Thread.State: WAITING (parking) at >>>> sun.misc.Unsafe.park(Native Method) - parking to wait for >>>> <0x0000000080f0cdb0> (a >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > > Same >>>> > here. > > The others look okay to me. > > -chris >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> -- > > > -- Enrico Olivelli > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
