glassfish
  1. glassfish
  2. GLASSFISH-15017

cpu 100% after grizzly-comet sends/receives large chunks of data

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1_b30
    • Fix Version/s: 3.1_ms07
    • Component/s: grizzly-kernel
    • Labels:
      None
    • Environment:

      Linux marc 2.6.32-26-generic-pae #48-Ubuntu SMP Wed Nov 24 10:31:20 UTC 2010 i686 GNU/Linux

      Description

      I have a problem when sending/receiving large Strings from/to Comet-grizzly. I've uploaded a simple example at http://lodgon.com/johan/comettest.zip
      The example consists of 2 parts:

      1. CometTestServer: a WAR with 2 servlets and a CometHandler.

      2. CometTestClient: a Java client with a Main class and a AsyncRedReader class that calls a servlet and receives input.

      The basic idea is to send a String from the client to the server, and the server uses Comet to send it to all registered clients.

      In the Main class on the client, I can set the size of the message. In case the message is small (< 100K characters, it works fine). In case the message is large (e.g. > 100K characters), no input is received. Sometimes, this already happens with 1 client, while during other attempts I have to start e.g. 4 clients before it stops working.

      The Glassfish server uses 100% CPU once the problem occurs, a Grizzly TCP Selector thread keeps running and uses a CPU. The stacktrace below is a snapshot generated by

      asadmin generate-jvm-report --type=thread

      Thread "Thread-41" thread-id: 92 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:237)
      at: sun.nio.ch.IOUtil.read(IOUtil.java:210)
      at: sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236)
      at: com.sun.grizzly.comet.CometTask.checkIfClientClosedConnection(CometTask.java:192)
      at: com.sun.grizzly.comet.CometTask.handleSelectedKey(CometTask.java:178)
      at: com.sun.grizzly.SelectorHandlerRunner.handleSelectedKey(SelectorHandlerRunner.java:274)
      at: com.sun.grizzly.SelectorHandlerRunner.handleSelectedKeys(SelectorHandlerRunner.java:258)
      at: com.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:195)
      at: com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:130)
      at: java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
      at: java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
      at: java.lang.Thread.run(Thread.java:619)

      Most of the snapshots I take have this Thread in CometTask.checkIfClientClosedConnection, but it seems to be looping forever somewhere. The execution time of this thread is equal to the time since the client-hang occurs.

      Note that the CometHandler.onEvent() tells that everything has been sent to the client, but the client didn't receive anything.

      I added some debug info to Comet (grizzly-comet 1.9.18o) and I have more info:

      when sending small messages, the CometTask.handleSelectedKey(SelectionKey selectionKey) only gets called when the client closes the connection.

      With large messages, this method is called infintely after comet has written the message to the output:

      [#|2010-12-06T21:17:07.897+0100|SEVERE|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=31;_ThreadName=Thread-1;|java.lang.Exception: Stack trace
      at java.lang.Thread.dumpStack(Thread.java:1206)
      at com.sun.grizzly.comet.CometTask.handleSelectedKey(CometTask.java:163)
      at com.sun.grizzly.SelectorHandlerRunner.handleSelectedKey(SelectorHandlerRunner.java:274)
      at com.sun.grizzly.SelectorHandlerRunner.handleSelectedKeys(SelectorHandlerRunner.java:258)
      at com.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:195)
      at com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:130)
      at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
      at java.lang.Thread.run(Thread.java:619)

        Activity

        No work has yet been logged on this issue.

          People

          • Assignee:
            oleksiys
            Reporter:
            johanvos
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: