ICEfaces
  1. ICEfaces
  2. ICE-2084

ICEfaces AHS: AHS sockets in CLOSE_WAIT state

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 1.6, 1.6.1
          • Fix Version/s: 1.6.1
          • Component/s: None
          • Labels:
            None
          • Environment:
            ICEfaces Asynchronous HTTP Server

            Description

            After a period of time, sockets used by the asynch server may enter the CLOSE_WAIT state and not be closed.

              Activity

              Descending order - Click to sort in ascending order
              Hide
              Permalink
              Jack Van Ooststroom added a comment -

              This was quite the tricky issue... Before when there was something to read of a particular connection, we unregistered for the OP_READ for this particular channel. We kept it unregistered until an HTTP Response was send back to the client. However, in the case of ICEfaces it could take a while before an HTTP Response becomes available of course. Now it could happen that Apache decides to close this particular connection. As we were uninterested in the OP_READ in this particular case, we wouldn't see the EOS and the socket ends up into a CLOSE_WAIT state.

              To fix this issue, after the full HTTP Request has been read we immediately register for the OP_READ for this particular channel again. If an EOS comes in we can do the proper clean up tasks and the socket doesn't end up into a CLOSE_WAIT state, but actually gets closed nicely. This solves the socket-leak. Marking this one as FIXED.

              Show
              Jack Van Ooststroom added a comment - This was quite the tricky issue... Before when there was something to read of a particular connection, we unregistered for the OP_READ for this particular channel. We kept it unregistered until an HTTP Response was send back to the client. However, in the case of ICEfaces it could take a while before an HTTP Response becomes available of course. Now it could happen that Apache decides to close this particular connection. As we were uninterested in the OP_READ in this particular case, we wouldn't see the EOS and the socket ends up into a CLOSE_WAIT state. To fix this issue, after the full HTTP Request has been read we immediately register for the OP_READ for this particular channel again. If an EOS comes in we can do the proper clean up tasks and the socket doesn't end up into a CLOSE_WAIT state, but actually gets closed nicely. This solves the socket-leak. Marking this one as FIXED.
              Hide
              Permalink
              Jack Van Ooststroom added a comment -

              The fix for this issue is targeted for ICEfaces Asynchronous HTTP Server 1.6.1a.

              Show
              Jack Van Ooststroom added a comment - The fix for this issue is targeted for ICEfaces Asynchronous HTTP Server 1.6.1a.

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  Ted Goddard
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: