Ok. I will try to debug the issue this weekend. Josep
*Josep M Beleta* *Director de Tecnologia* Carver Advanced Systems, S.L. París, 184. 4º 08036 - Barcelona Tel: 93 238 5880 Fax: 93 238 5881 *segueix-nos <http://www.linkedin.com/company/carver-advanced-systems-s.l.>* <http://twitter.com/#%21/carver_as> <https://plus.google.com/112583630853594851700?prsrc=3> www.carver-as.com 2016-04-13 13:35 GMT+02:00 Mark Thomas <ma...@apache.org>: > On 13/04/2016 12:11, Josep M Beleta wrote: > > I was wrong in my last message. One of the threads is different, is is > not > > related to AJP. This thread is: > > > > "NioBlockingSelector.BlockPoller-2" #15 daemon prio=5 os_prio=0 > > tid=0x000000001ce0c800 nid=0x19b8 runnable [0x000000001dfff000] > > java.lang.Thread.State: RUNNABLE > > at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method) > > at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(Unknown Source) > > at sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(Unknown Source) > > at sun.nio.ch.WindowsSelectorImpl.doSelect(Unknown Source) > > at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source) > > - locked <0x00000006c016abd0> (a sun.nio.ch.Util$2) > > - locked <0x00000006c016abc0> (a java.util.Collections$UnmodifiableSet) > > - locked <0x00000006c016aa50> (a sun.nio.ch.WindowsSelectorImpl) > > at sun.nio.ch.SelectorImpl.select(Unknown Source) > > at > > > org.apache.tomcat.util.net.NioBlockingSelector$BlockPoller.run(NioBlockingSelector.java:342) > > > > Locked ownable synchronizers: > > - None > > > > All they have in common is that all them are running inside > > sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0. > > Isolating it to the poller threads is very helpful. > > > Could be a Java problem? > > Maybe. A Tomcat bug is more likely at this point. > > > Could I find a workaround? > > We need to figure out the root cause first... > > > What could have been the cause that triggered that behavior? > > Hard to say. Maybe some edge case error condition that puts things into > an unexpected state. > > It sounds like the Poller is in a tight loop. The next thing to figure > out is what code path it is following and why. Are you able to configure > a test instance to allow remote debugging? If you can, wait for the > problem to occur, set a break point on NioBlockingSelector.java:342, and > attach the debugger. Check that the poller thread keeps coming back to > this point. If it does, step through the code and record the path followed. > > Alternatively, if you find a way to recreate the issue, other people on > this list will be able to help investigate. > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
