ICEpush
  1. ICEpush
  2. PUSH-410

Allow for multiple pending Cloud Push Notifications for a single Browser-ID

          Details

          • Type: New Feature New Feature
          • Status: Resolved
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: EE-4.0.0.GA, 4.1
          • Fix Version/s: EE-4.2.0.GA
          • Component/s: Push Library
          • Labels:
            None
          • Environment:
            ICEpush, Cloud Push

            Description

            Allow for multiple pending Cloud Push Notifications for a single Browser-ID even when issued in a more rapid succession. It is up to the developer to throttle if needed.

              Issue Links

              depends on

              Bug - A problem which impairs or prevents the functions of the product. PUSH-409 Multiple Cloud Push Notifications are created for the same Browser-ID from a single Out-of-Band Notification

              • Major - Major loss of function.
              • Closed

                Activity

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

                The ConfirmationTimeout now holds a Set containing CloudPushNotifications. This new CloudPushNotification class holds the usual browserID, propertyMap, and such which were previously contained within the ConfirmationTimeout itself. Both classes are responsible for proper clean-up to avoid undesired collection growth. When a listen.icepush request comes in the original logic still stands where any pending CloudPushNotification (before ConfirmationTimeout) associated with the incoming Browser-ID gets cancelled unless a CloudPushNotification is marked as forced. Marking this one as FIXED.

                Show
                Jack Van Ooststroom added a comment - - edited The ConfirmationTimeout now holds a Set containing CloudPushNotifications . This new CloudPushNotification class holds the usual browserID , propertyMap , and such which were previously contained within the ConfirmationTimeout itself. Both classes are responsible for proper clean-up to avoid undesired collection growth. When a listen.icepush request comes in the original logic still stands where any pending CloudPushNotification (before ConfirmationTimeout ) associated with the incoming Browser-ID gets cancelled unless a CloudPushNotification is marked as forced . Marking this one as FIXED.
                Hide
                Permalink
                Jack Van Ooststroom added a comment -

                Sending icepush-ee/core/src/main/java/org/icepush/ConfirmationTimeout.java
                Sending icepush-ee/core/src/main/java/org/icepush/LocalPushGroupManager.java
                Transmitting file data ..
                Committed revision 48702.

                Sending icepush-ee/eps/src/main/java/com/icesoft/push/ConfirmationTimeout.java
                Sending icepush-ee/eps/src/main/java/com/icesoft/push/LocalPushGroupManager.java
                Transmitting file data ..
                Committed revision 45030.

                Show
                Jack Van Ooststroom added a comment - Sending icepush-ee/core/src/main/java/org/icepush/ConfirmationTimeout.java Sending icepush-ee/core/src/main/java/org/icepush/LocalPushGroupManager.java Transmitting file data .. Committed revision 48702. Sending icepush-ee/eps/src/main/java/com/icesoft/push/ConfirmationTimeout.java Sending icepush-ee/eps/src/main/java/com/icesoft/push/LocalPushGroupManager.java Transmitting file data .. Committed revision 45030.

                  People

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

                    Dates

                    • Created:
                      Updated:
                      Resolved: