Bugzilla – Full Text Bug Listing
| Summary: | 100% CPU consumed when started via xinetd/InheritedChannelConnector | ||
|---|---|---|---|
| Product: | [RT] Jetty | Reporter: | Michael Dobrovnik <michi> |
| Component: | server | Assignee: | Greg Wilkins <gregw> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jetty-inbox |
| Version: | 7.5.0 | ||
| Target Milestone: | 7.5.x | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
Thanks for this. Your fix is good, as we did indeed change to having blocking acceptors. This shows that we really need a test harness for this connector. |
Startup of etty 7.5.0 via xinetd works pretty well, but even on idle servers 100% CPU is consumed. The log shows repetitions of the following NPEs with no pause whatsoever: 2011-09-07 22:15:19.415:WARN:oejs.AbstractConnector: java.lang.NullPointerException at org.eclipse.jetty.server.nio.SelectChannelConnector.accept(SelectChannelConnector.java:98) at org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:833) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533) at java.lang.Thread.run(Thread.java:662) There seems to be a "tight" loop in AbstractConnector$Acceptor.run, because _acceptChannel.accept() returns null. The __acceptChannel SelectChannelConnector has been set to nonblocking in InheritedChannelConnector.open(). Looking at the SelectChannelConnector which is well behaved, it can be seen that it sets its selectchannelconnector to blocking; so it may be appropriate to change line 58 of InheritedChannelConnector to: _acceptChannel.configureBlocking(true); A brief test with this change showed that the issue dissappeared. Thanks for your efforts and of course for Jetty in general!