Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Load testing slowness
OK. Upon re-running the test, I saw the QTP threads blocked by a different monitor. Here's the blocker at the time of my latest thread dump:

"qtp1855107489-244" prio=10 tid=0x00007f4df4c8c000 nid=0x8b8 runnable [0x00007f4dcc483000]
   java.lang.Thread.State: RUNNABLE
        at org.eclipse.jetty.io.BufferDateCache.formatBuffer(BufferDateCache.java)
        - locked <0x0000000780b26fb8> (a org.eclipse.jetty.io.BufferDateCache)
        at org.eclipse.jetty.server.Request.getTimeStampBuffer(Request.java:1213)
        at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:859)
        at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:637)
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
        at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:77)
        at org.eclipse.jetty.io.nio.SslConnection.handle(SslConnection.java:191)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:606)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:46)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538)
        at java.lang.Thread.run(Thread.java:679)

And here's one of the threads being blocked:

"qtp1855107489-242" prio=10 tid=0x00007f4df0463000 nid=0x8b7 waiting for monitor entry [0x00007f4dcc584000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at org.eclipse.jetty.io.BufferDateCache.formatBuffer(BufferDateCache.java)
        - waiting to lock <0x0000000780b26fb8> (a org.eclipse.jetty.io.BufferDateCache)
        at org.eclipse.jetty.server.Request.getTimeStampBuffer(Request.java:1213)
        at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:859)
        at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:637)
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
        at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:77)
        at org.eclipse.jetty.io.nio.SslConnection.handle(SslConnection.java:191)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:606)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:46)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538)
        at java.lang.Thread.run(Thread.java:679)

Strangely, I'm seeing the same behavior in yourkit as with the previous tests, but these threads are blocking in BufferDataCache rather than ServletHolder. And just to confirm, what I'm seeing is not simply N threads permanently blocked by one, but N threads spending most of their time blocked and briefly becoming runnable intermittently. 

On Wed, Dec 19, 2012 at 3:03 PM, Simone Bordet <sbordet@xxxxxxxxxxx> wrote:
[0x00007fa34a6e9000

Back to the top