On Fri, Oct 4, 2019 at 3:40 PM Emmanuel Lecharny <elecha...@apache.org> wrote:
> Hi ! > > I filled a ticket yesterday about a pb we face with many NIO framework, > which I think could hit Tomcat too (see > https://bz.apache.org/bugzilla/show_bug.cgi?id=63802). Actually, I think > I'm facing this problem on a project I'm working on atm. > > Remy suggested we discuss it on this mailing list. > > Bottom line, what happens is that under some circumstances not well > defined, the call to select() might end to an infinite loop eating all the > CPU (select() returns 0, so select is immediately called again, and we > loop). > > In various NIO framworks - and being a MINA committer, I have implemented > the discussed workaround -, we are controlling this situation by breaking > this infinite loop this way : > - if the select() call returns 0 > - then if we have called select() more than N times in less than M ms > (N=10, M=100 in MINA) > - then we create a new Selector, register all the selectionKey that were > registered on the broken selector, and ditch the old selector. > > This workaround does not cost a lot when the selector works as designed, > as a select() call should never return 0. > There's actually a very similar hack for APR that has been placed by myself a long time ago [ https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/util/net/AprEndpoint.java#L1410 ], I don't even know if it's actually useful and it's certainly not testable. Overall what it does is pretty terrible :( Personally I would like to know more about this "long lived bug either in the JDK or even in Linux epoll implementation" like actual platform details and JVM versions used since I've never heard about it in the first place. Also I'd like to know since NIO2 doesn't expose its poller and almost certainly doesn't have such a platform specific mysterious thing inside it [we can check I guess]. In the context of NIO, do you have evidence the hack has been tested to work (besides avoiding the CPU loop) and allowed the server to continue its regular operation without any impact ? Rémy > > I suggest Tomcat add such a workaround in the various versions (8 and 9 at > least). > > Emmanuel Lécharny > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
