Uploaded image for project: 'JBoss Enterprise Application Platform 4 and 5'
  1. JBoss Enterprise Application Platform 4 and 5
  2. JBPAPP-5748

[JBossWS] FastInfoSet leaving sockets in CLOSE_WAIT state

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • EAP_EWP 5.1.1
    • EAP_EWP 5.1.0
    • Remoting
    • JBoss EAP 5.1.0, Sun JDK 1.6.0_22, RHEL6

    • Hide

      Each zip contains source files as well as deployables:

      opensocket-jbm-queue-service.xml

      • This is the definition of a JBoss Messaging queue. Please deploy this first

      FastInfosetWebProject.war

      • Please excuse the name here, have double used this project. Ignore the class FastInfosetServlet as this is not used. In this case, there is a servlet called OpenSocketServlet that I'm using as a client. When that servlet is invoked, it sends 1,000 messages to the JMS queue listed above and then returns to the browser that it has done this.

      OpenSocketEjbProject.jar

      • This is the MDB that gets the JMS messages sent above, then it calls back to a WS in the FastInfosetWebProject.war for each JMS message that it gets. The web service (in the war above) will print out to stdout every time it receives 200 more messages (just so you can see that things are happening).

      To reproduce:

      1.) Deploy the queue XML file, then the WAR file, then the EJB JAR file.
      2.) Hit this URL in a browswer: http://localhost:8080/FastInfosetWebProject/OpenSocketServlet?name=World
      3.) Right away, go ahead an hit that same URL again
      4.) Open a terminal window and run this command: ""netstat -an | grep -i close_wait | grep 127.0.0.1:8080 | wc -l
      5.) Note that initially there are 0.
      6.) Note that after the server is running for awhile there may be 100-200 matches
      7.) Note that even after the server finishes working (do top or something to see that everything is done), There should still be 150 or so CLOSE_WAIT sockets open.
      8.) Note that these CLOSE_WAIT items will stay there for quite awhile (minutes usually) and then evenually they will go to 0. Also, if you shut down JBoss they should go to 0 immediately.

      Show
      Each zip contains source files as well as deployables: opensocket-jbm-queue-service.xml This is the definition of a JBoss Messaging queue. Please deploy this first FastInfosetWebProject.war Please excuse the name here, have double used this project. Ignore the class FastInfosetServlet as this is not used. In this case, there is a servlet called OpenSocketServlet that I'm using as a client. When that servlet is invoked, it sends 1,000 messages to the JMS queue listed above and then returns to the browser that it has done this. OpenSocketEjbProject.jar This is the MDB that gets the JMS messages sent above, then it calls back to a WS in the FastInfosetWebProject.war for each JMS message that it gets. The web service (in the war above) will print out to stdout every time it receives 200 more messages (just so you can see that things are happening). To reproduce: 1.) Deploy the queue XML file, then the WAR file, then the EJB JAR file. 2.) Hit this URL in a browswer: http://localhost:8080/FastInfosetWebProject/OpenSocketServlet?name=World 3.) Right away, go ahead an hit that same URL again 4.) Open a terminal window and run this command: ""netstat -an | grep -i close_wait | grep 127.0.0.1:8080 | wc -l 5.) Note that initially there are 0. 6.) Note that after the server is running for awhile there may be 100-200 matches 7.) Note that even after the server finishes working (do top or something to see that everything is done), There should still be 150 or so CLOSE_WAIT sockets open. 8.) Note that these CLOSE_WAIT items will stay there for quite awhile (minutes usually) and then evenually they will go to 0. Also, if you shut down JBoss they should go to 0 immediately.
    • Workaround Exists
    • Hide

      Remove the fastInfoSet from the web service.

      Show
      Remove the fastInfoSet from the web service.
    • Medium
    • Hide
      Sending multiple requests from a WS client and using fastinfoset caused an increase of sockets in a CLOSE_WAIT state and incorrect shutdown. This issue was fixed by introducing the org.jboss.ws.client.remoting.disconnect.after.use JVM property, which causes the client remote to disconnect immediately. This property is enabled by default. If you disable it, HttpURLConnections remain open.
      Show
      Sending multiple requests from a WS client and using fastinfoset caused an increase of sockets in a CLOSE_WAIT state and incorrect shutdown. This issue was fixed by introducing the org.jboss.ws.client.remoting.disconnect.after.use JVM property, which causes the client remote to disconnect immediately. This property is enabled by default. If you disable it, HttpURLConnections remain open.
    • Documented as Resolved Issue

      When sending multiple requests from a ws client and using fastinfoset we see the number of sockets in a CLOSE_WAIT state increase and not get shut down properly. Removing fastinfoset from the code fixed this issue and increasing the verbosity of the logging of the soap message also removes this issue.

      I am attaching the following files for both scenarios (one with and one without

      Projects.zip

      • These are the JBDS projects that created the WAR and JAR above so that you can see the source code - This uses FastInfoSet and will reproduce the issue.

      fixedProject.zip

      • These are the JBDS projects that created the WAR and JAR above so that you can see the source code - This DOES NOT uses FastInfoSet and will not reproduce the issue

        1. fixProject.zip
          69 kB
        2. JBPAPP-5748.patch
          5 kB
        3. Projects.zip
          54 kB

              ropalka Richard Opalka
              rhn-support-mus Mustafa Musaji
              Rebecca Newton Rebecca Newton (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: