ICEpush
  1. ICEpush
  2. PUSH-243

Ensure Cloud Push is delivered when subsequent listen does not occur

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.3
    • Fix Version/s: EE-3.3.0.GA
    • Component/s: Push Library
    • Labels:
      None
    • Environment:
      ICEpush, ICEfaces, ICEmobile
    • Assignee Priority:
      P1

      Description

      One of the detection cases for Cloud Push is that a notification is sent, but not acknowledged via a subsequent listen.icepush.

      This is currently reproducible in mobileshowcase with a 5 second Priority Push.

        Activity

        Ted Goddard created issue -
        Ted Goddard made changes -
        Field Original Value New Value
        Assignee Jack Van Ooststroom [ jack.van.ooststroom ]
        Ken Fyten made changes -
        Assignee Priority P1 [ 10010 ]
        Hide
        Jack Van Ooststroom added a comment -

        Since the fixes to PUSH-244 and PUSH-245 I haven't been able to reproduce this anymore. However, when I was originally able to reproduce it, I didn't see the ConcurrentModificationException nor was I using logging at Level.FINE level. Therefore I'm in doubt that the fixes to PUSH-244 and PUSH-245 could have resolved this issue. But as I can't reproduce it anymore I'll mark this one as Cannot Reproduce. If Ted and/or Steve can reproduce it again we can re-open this one.

        As Ted noted that he suspects a Cloud Push not having been confirmed correctly upon a subsequent listen.icepush request (either by the lack of that request or something at the server-side going awry) it could get into the case where the server decides not to schedule the ConfirmationTimeout due to the following if-statement:

        long now = System.currentTimeMillis();
        long timeout = status.getConnectionRecreationTimeout() * 2;
        if (notifyBackURI.getTimestamp() + minCloudPushInterval <= now + timeout)

        { return startConfirmationTimeout(sequenceNumber, timeout); }

        else {
        if (LOGGER.isLoggable(Level.FINE))

        { LOGGER.log( Level.FINE, "Timeout is within the minimum Cloud Push interval for URI '" + notifyBackURI + "'. (" + "timestamp: '" + notifyBackURI.getTimestamp() + "', " + "minCloudPushInterval: '" + minCloudPushInterval + "', " + "now: '" + now + "', " + "timeout: '" + timeout + "'" + ")"); }

        }

        If the NotifyBackURI instance doesn't get touched when expected it could happen that, especially with the 5 second Priority Push, the Server decides not to schedule the ConfirmationTimeout as part of its flood prevention logic.

        Show
        Jack Van Ooststroom added a comment - Since the fixes to PUSH-244 and PUSH-245 I haven't been able to reproduce this anymore. However, when I was originally able to reproduce it, I didn't see the ConcurrentModificationException nor was I using logging at Level.FINE level. Therefore I'm in doubt that the fixes to PUSH-244 and PUSH-245 could have resolved this issue. But as I can't reproduce it anymore I'll mark this one as Cannot Reproduce. If Ted and/or Steve can reproduce it again we can re-open this one. As Ted noted that he suspects a Cloud Push not having been confirmed correctly upon a subsequent listen.icepush request (either by the lack of that request or something at the server-side going awry) it could get into the case where the server decides not to schedule the ConfirmationTimeout due to the following if-statement: long now = System.currentTimeMillis(); long timeout = status.getConnectionRecreationTimeout() * 2; if (notifyBackURI.getTimestamp() + minCloudPushInterval <= now + timeout) { return startConfirmationTimeout(sequenceNumber, timeout); } else { if (LOGGER.isLoggable(Level.FINE)) { LOGGER.log( Level.FINE, "Timeout is within the minimum Cloud Push interval for URI '" + notifyBackURI + "'. (" + "timestamp: '" + notifyBackURI.getTimestamp() + "', " + "minCloudPushInterval: '" + minCloudPushInterval + "', " + "now: '" + now + "', " + "timeout: '" + timeout + "'" + ")"); } } If the NotifyBackURI instance doesn't get touched when expected it could happen that, especially with the 5 second Priority Push, the Server decides not to schedule the ConfirmationTimeout as part of its flood prevention logic.
        Jack Van Ooststroom made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Cannot Reproduce [ 5 ]
        Ted Goddard made changes -
        Resolution Cannot Reproduce [ 5 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Hide
        Jack Van Ooststroom added a comment -

        Sending core/src/main/java/org/icepush/BlockingConnectionServer.java
        Sending core/src/main/java/org/icepush/LocalPushGroupManager.java
        Sending core/src/main/java/org/icepush/PushID.java
        Transmitting file data ...
        Committed revision 35904.

        Show
        Jack Van Ooststroom added a comment - Sending core/src/main/java/org/icepush/BlockingConnectionServer.java Sending core/src/main/java/org/icepush/LocalPushGroupManager.java Sending core/src/main/java/org/icepush/PushID.java Transmitting file data ... Committed revision 35904.
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #35904 Tue Jun 04 18:09:37 MDT 2013 jack.van.ooststroom Fixed JIRA PUSH-243 : Ensure Cloud Push is delivered when subsequent listen does not occur
        Files Changed
        Commit graph MODIFY /icepush/trunk/icepush/core/src/main/java/org/icepush/PushID.java
        Commit graph MODIFY /icepush/trunk/icepush/core/src/main/java/org/icepush/LocalPushGroupManager.java
        Commit graph MODIFY /icepush/trunk/icepush/core/src/main/java/org/icepush/BlockingConnectionServer.java
        Hide
        Jack Van Ooststroom added a comment -

        The culprit here was that once the NotifyBackURI was set on the BlockingConnectionServer new PushID objects wouldn't get a NotifyBackURI set on it. The BlockingConnectionServer now always invokes the PushGroupManager.setNotifyBackURI if the incoming Request contains a ice.notifyBack. The com.icesoft.push.LocalPushGroupManager already ensures that a SetNotifyBackURI message is only send if a change has been detected. As it iterates over the Push IDs, if a Push ID's NotifyBackURI didn't change, it will be touched. Finally, the Push ID's NotifyBackURI reference is only updated if there is indeed a change. Marking this one as FIXED.

        Show
        Jack Van Ooststroom added a comment - The culprit here was that once the NotifyBackURI was set on the BlockingConnectionServer new PushID objects wouldn't get a NotifyBackURI set on it. The BlockingConnectionServer now always invokes the PushGroupManager.setNotifyBackURI if the incoming Request contains a ice.notifyBack. The com.icesoft.push.LocalPushGroupManager already ensures that a SetNotifyBackURI message is only send if a change has been detected. As it iterates over the Push IDs, if a Push ID's NotifyBackURI didn't change, it will be touched. Finally, the Push ID's NotifyBackURI reference is only updated if there is indeed a change. Marking this one as FIXED.
        Jack Van Ooststroom made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Jack Van Ooststroom
            Reporter:
            Ted Goddard
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: