Bugzilla – Full Text Bug Listing
| Summary: | CPU spike in WebSocketConnectionD00 | ||
|---|---|---|---|
| Product: | [RT] Jetty | Reporter: | jfarcand <jfarcand> |
| Component: | websocket | Assignee: | Greg Wilkins <gregw> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jetty-inbox |
| Version: | unspecified | ||
| Target Milestone: | 7.5.x | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
We made some changes to the D00 parser for http://jira.codehaus.org/browse/JETTY-1463 - which improved several aspects of the D00 handling. Can you try RC2 build? Failing that, any clue you can give us as to what state these connection are in would be really helpful - ie is the client closed, TIME_WAIT, CLOSE_WAIT??? etc. I've improved the D00 test harness with some more close tests and no problems found so far. in 7.6 and 8.1 |
Build Identifier: CPU is going up (quite up) and we traced the issue is caused by this call. "qtp1367996500-242" prio=10 tid=0x00002aabc8e49000 nid=0x7c5a runnable [0x0000000046b93000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.FileDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) at sun.nio.ch.IOUtil.read(IOUtil.java:206) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236) - locked <0x00002aaae6d12568> (a java.lang.Object) at org.eclipse.jetty.io.nio.ChannelEndPoint.fill(ChannelEndPoint.java:230) - locked <0x00002aaae6d09608> (a java.nio.HeapByteBuffer) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.fill(SelectChannelEndPoint.java:300) at org.eclipse.jetty.websocket.WebSocketConnectionD00.handle(WebSocketConnectionD00.java:119) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:609) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:45) 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:619) I understand this is not simple to track, so let me know what kind of logging I can share in order to fix the issue. One workaround I have right now is to downgrade to long-polling when I detect this version of the protocol websocket, but I don't like the solution. Reproducible: Always