ICEpush
  1. ICEpush
  2. PUSH-92

ICEpush Bridge: incorrect behavior regarding the listen.icepush blocking request

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-Beta
    • Fix Version/s: 2.0-Beta
    • Component/s: Push Library
    • Labels:
      None
    • Environment:
      ICEpush Core, icepush-jsp-push

      Description

         1. Using icepush-jsp-push and icepush-jsp-cluster (my own test application) the blocking connection seems to behave oddly. A listen.icepush request is issued to the server and handled by the application. I'm not interacting with the page at all. After 50 seconds the server decides to send a <noop /> response back to the Bridge. I would expect the Bridge to re-issue a listen.icepush request upon receiving the <noop /> response. This does not seem to happen anymore.

         2. Using icepush-jsp-cluster with EPS the blocking connection again seems to behave oddly. A listen.icepush request is issued and handled by the EPS. I'm not interacting with the page at all. Just before 50 seconds the Bridge issues another listen.icepush request before receiving any response to the previous one. EPS decides (using Core code) to response with an X-Connection: close to the previous listen.icepush request and handles the current listen.icepush request. After about 25 seconds the Bridge issues another listen.icepush request again before receiving any response to the previous one. EPS decides (using Core code) to response with an X-Connection: close to the previous listen.icepush request and handles the current listen.icepush request. After 12 seconds or so the blocking connection is dead.

        Activity

        Hide
        Jack Van Ooststroom added a comment -

        Assigning to Mircea for investigation.

        Show
        Jack Van Ooststroom added a comment - Assigning to Mircea for investigation.
        Hide
        Jack Van Ooststroom added a comment -

        Changed Fix Version/s to 2.0-Beta

        Show
        Jack Van Ooststroom added a comment - Changed Fix Version/s to 2.0-Beta
        Hide
        Mircea Toma added a comment -

        The connection timeout detection introduced by PUSH-82 is configured to assume that the connection is in trouble when the bridge doesn't receives an answer after a period equal to 'heartbeat timeout' + 300ms. It seems that the 300ms difference is too short because even when running the test on a local machine the bridge doesn't receive and process the <noop/> response sent by the server (for each heartbeat) . As a result the timeout mechanism kicks in assuming the connection is in trouble. The connection is re-established by the timeout mechanism but the next timeout used is half the heartbeat interval, but since the <noop/> response was lost the second retry fails as well.
        The fix applied changes the additional timout to 5 seconds (instead of 300ms). Also modified connection timeout mechanism to use equal intervals between retries.

        Show
        Mircea Toma added a comment - The connection timeout detection introduced by PUSH-82 is configured to assume that the connection is in trouble when the bridge doesn't receives an answer after a period equal to 'heartbeat timeout' + 300ms. It seems that the 300ms difference is too short because even when running the test on a local machine the bridge doesn't receive and process the <noop/> response sent by the server (for each heartbeat) . As a result the timeout mechanism kicks in assuming the connection is in trouble. The connection is re-established by the timeout mechanism but the next timeout used is half the heartbeat interval, but since the <noop/> response was lost the second retry fails as well. The fix applied changes the additional timout to 5 seconds (instead of 300ms). Also modified connection timeout mechanism to use equal intervals between retries.

          People

          • Assignee:
            Mircea Toma
            Reporter:
            Jack Van Ooststroom
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: