Description jfarcand 2011-12-22 10:55:46 EST

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