Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.3
    • Fix Version/s: 4.0.BETA, 4.0
    • Labels:
      None
    • Environment:
      ICEpush, ICEpush service
    • Assignee Priority:
      P2
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.)

      Description

      A push delivery window specified by delay and duration causes push updates to be delivered within a window o f time in the near future. This provides opportunities for moderating server load and improving application functionality.

        Activity

        Ted Goddard created issue -
        Ted Goddard made changes -
        Field Original Value New Value
        Assignee Jack Van Ooststroom [ jack.van.ooststroom ]
        Ted Goddard made changes -
        Fix Version/s 3.4 [ 10971 ]
        Hide
        Ted Goddard added a comment -

        With ICEpush, a single notification can rapidly notify a very
        large number of (distributed) clients, each of which will suddenly
        make a new HTTP request for their updates. These can easily be
        new sockets, so can overwhelm the TCP accept queue and the
        Servlet engine on the server (because the CPU and stack depth
        requirements for processing an application request are much
        heaver than that for handling an ICEpush request).

        This can be resolved by introducing a "push delivery window":
        essentially a time interval in the future specifying when the
        notifications should occur. This can be specified as a delay
        and a duration. For instance a push to "chat" with delay 5000
        and duration 10000 would wait for 5 seconds to send push
        notifications to the group "chat", spreading the network activity
        over the following 10 seconds.

        There are a variety of uses for this:

        • the initial delay allows for data to be updated in the back-end
          before the push occurs
        • a delay allows for coalescing server-side which can improve
          scalability by throttling rapid updates to individual clients
          Given two updates with delays and delivery durations,
          if the duration regions overlap, a single notification can be
          delivered within the region of overlap.
        • the duration spreads server load across time, making CPU and
          network traffic less bursty
        • the duration indicates when notifications need to be delivered
          allowing ICEpush to log a warning when it cannot meet QoS
          requirements (more important for ICEpush-as-a-service)
        • the initial delay can be used for application functionality, such
          as a demo feature (many of our demos have these push delays), or
          say, a short sequence of delayed notifications to cover progress
          of a background process

        This can be added through the PushConfiguration API (which currently
        allows Cloud Push to be configured), although the first priority is
        actually to support it with the JavaScript API.

        Show
        Ted Goddard added a comment - With ICEpush, a single notification can rapidly notify a very large number of (distributed) clients, each of which will suddenly make a new HTTP request for their updates. These can easily be new sockets, so can overwhelm the TCP accept queue and the Servlet engine on the server (because the CPU and stack depth requirements for processing an application request are much heaver than that for handling an ICEpush request). This can be resolved by introducing a "push delivery window": essentially a time interval in the future specifying when the notifications should occur. This can be specified as a delay and a duration. For instance a push to "chat" with delay 5000 and duration 10000 would wait for 5 seconds to send push notifications to the group "chat", spreading the network activity over the following 10 seconds. There are a variety of uses for this: the initial delay allows for data to be updated in the back-end before the push occurs a delay allows for coalescing server-side which can improve scalability by throttling rapid updates to individual clients Given two updates with delays and delivery durations, if the duration regions overlap, a single notification can be delivered within the region of overlap. the duration spreads server load across time, making CPU and network traffic less bursty the duration indicates when notifications need to be delivered allowing ICEpush to log a warning when it cannot meet QoS requirements (more important for ICEpush-as-a-service) the initial delay can be used for application functionality, such as a demo feature (many of our demos have these push delays), or say, a short sequence of delayed notifications to cover progress of a background process This can be added through the PushConfiguration API (which currently allows Cloud Push to be configured), although the first priority is actually to support it with the JavaScript API.
        Hide
        Ted Goddard added a comment -

        A future variant of the API could allow the delivery window to be specified in absolute times (effectively more of a scheduler).

        A more complex variant could allow more advanced properties on the interval, such as an acceptable delay ("should") and a required delay ("must"). One way to specify this would be an interval on the delay itself. Additional complexity of this variety must be driven by known application requirements.

        Show
        Ted Goddard added a comment - A future variant of the API could allow the delivery window to be specified in absolute times (effectively more of a scheduler). A more complex variant could allow more advanced properties on the interval, such as an acceptable delay ("should") and a required delay ("must"). One way to specify this would be an interval on the delay itself. Additional complexity of this variety must be driven by known application requirements.
        Hide
        Ted Goddard added a comment - - edited

        PushNotification notification = new PushNotification("Hello", "chat message here");
        notification.getAttributes().put("delay", 5000);
        notification.getAttributes().put("duration", 10000);
        PushContext.push("chat", notification);

        with API change:

        PushContext.push("chat", (new PushNotification(subject, detail)).with(new PushSchedule(5000, 10000)));

        If absolute time scheduling is added in a future implementation, this can be supported by Date types in the constructor. PushSchedule(5000) would simply be a delay.

        pushConfiguration.with(PushConfiguration moreConfig) simply includes the attributes of the parameter in the invoked object and returns itself.

        Show
        Ted Goddard added a comment - - edited PushNotification notification = new PushNotification("Hello", "chat message here"); notification.getAttributes().put("delay", 5000); notification.getAttributes().put("duration", 10000); PushContext.push("chat", notification); with API change: PushContext.push("chat", (new PushNotification(subject, detail)).with(new PushSchedule(5000, 10000))); If absolute time scheduling is added in a future implementation, this can be supported by Date types in the constructor. PushSchedule(5000) would simply be a delay. pushConfiguration.with(PushConfiguration moreConfig) simply includes the attributes of the parameter in the invoked object and returns itself.
        Ken Fyten made changes -
        Assignee Jack Van Ooststroom [ jack.van.ooststroom ] Mircea Toma [ mircea.toma ]
        Assignee Priority P2 [ 10011 ]
        Hide
        Ted Goddard added a comment -

        There might not be significant complications in a cluster: it is likely sufficient to relay the push window to the cluster nodes and have each one complete the notifications within the window. Significant clock skew or delays within the cluster would be a problem, but this can be assumed to not be a factor in a production system.

        Show
        Ted Goddard added a comment - There might not be significant complications in a cluster: it is likely sufficient to relay the push window to the cluster nodes and have each one complete the notifications within the window. Significant clock skew or delays within the cluster would be a problem, but this can be assumed to not be a factor in a production system.
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #38276 Wed Sep 25 03:34:46 MDT 2013 mircea.toma PUSH-268 Added application for testing push delivery window scenarios.
        Files Changed
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/web/WEB-INF/web.xml
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/src/main/webapp/WEB-INF/web.xml
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/src/main/java/org/icepush/sample/basic/NotificationSpreading.java
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/web
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/web/WEB-INF
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/src/main/webapp
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/src/main/java/org/icepush/sample
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/build.xml
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/src/main/java/org/icepush/sample/basic
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/src/main/resources
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/src/main/java/org
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/web/index.jsp
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/src/main
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/src/main/java
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/src/main/java/org/icepush
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/src/main/webapp/WEB-INF
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/src
        Hide
        Mircea Toma added a comment -

        Implemented push delivery window feature. Introduced new API for defining how and when notifications are to be delivered.

        Show
        Mircea Toma added a comment - Implemented push delivery window feature. Introduced new API for defining how and when notifications are to be delivered.
        Mircea Toma made changes -
        Affects Documentation (User Guide, Ref. Guide, etc.) [ 10003 ]
        Hide
        Mircea Toma added a comment - - edited

        Added icepush/samples/notification-scheduling application that can be used for testing notification delivery window scenarios.

        Show
        Mircea Toma added a comment - - edited Added icepush/samples/notification-scheduling application that can be used for testing notification delivery window scenarios.
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #38277 Wed Sep 25 03:40:23 MDT 2013 mircea.toma PUSH-268 Implemented push delivery window feature. Introduced new API for defining how and when notifications are to be delivered.
        Files Changed
        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/LocalNotificationBroadcaster.java
        Commit graph MODIFY /icepush/trunk/icepush/core/src/main/java/org/icepush/PushConfiguration.java
        Commit graph MODIFY /icepush/trunk/icepush/core/src/main/java/org/icepush/NotificationBroadcaster.java
        Commit graph MODIFY /icepush/trunk/icepush/core/src/main/java/org/icepush/BlockingConnectionServer.java
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #38282 Wed Sep 25 15:15:52 MDT 2013 mircea.toma PUSH-268 Use TreeSet.first method instead of TreeSet.pollFirst, the latter was introduced in JDK 1.6.
        Files Changed
        Commit graph MODIFY /icepush/trunk/icepush/core/src/main/java/org/icepush/LocalPushGroupManager.java
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #38286 Wed Sep 25 17:12:12 MDT 2013 mircea.toma PUSH-268 Fix notification time related tests. Simplify code.
        Files Changed
        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/LocalNotificationBroadcaster.java
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #38287 Thu Sep 26 08:39:39 MDT 2013 mircea.toma PUSH-268 Added test for notification window overlapping. Added index page for the test application.
        Files Changed
        Commit graph MODIFY /icepush/trunk/icepush/samples/notification-scheduling/src/main/webapp/WEB-INF/web.xml
        Commit graph MODIFY /icepush/trunk/icepush/core/src/main/java/org/icepush/LocalPushGroupManager.java
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/src/main/java/org/icepush/sample/basic/NotificationWindowOverlapping.java
        Commit graph DEL /icepush/trunk/icepush/samples/notification-scheduling/web
        Commit graph ADD /icepush/trunk/icepush/samples/notification-scheduling/src/main/webapp/index.jsp
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #38288 Thu Sep 26 09:20:02 MDT 2013 mircea.toma PUSH-268 Implemented client side API for notification scheduling and server side parameter decoding.
        Files Changed
        Commit graph MODIFY /icepush/trunk/icepush/core/src/main/javascript/application.js
        Commit graph MODIFY /icepush/trunk/icepush/core/src/main/java/org/icepush/servlet/BrowserBoundServlet.java
        Hide
        Mircea Toma added a comment -

        Implemented client side of the push delivery window feature. The ice.push.notify function can now accept a third parameter that is used to defined the scheduling of the notification.
        There are two ways of defining the scheduling:

        • Using a delayed notification
          ice.push.notifiy('a-group', {}, {delay: 3000, duration: 5500 });

          Here the notification is fired after a 3000ms delay and the notification is spread among the receiving browsers during a 5500 interval.

        • Using a scheduled notification
          var date = new Date("December 17, 2013 03:24:00");
          ice.push.notifiy('a-group', {}, {at: date.getTime(), duration: 5500 });

          Here the notification is fired at the specified time and the notification is spread among the receiving browsers during a 5500 interval.

        Show
        Mircea Toma added a comment - Implemented client side of the push delivery window feature. The ice.push.notify function can now accept a third parameter that is used to defined the scheduling of the notification. There are two ways of defining the scheduling: Using a delayed notification ice.push.notifiy('a-group', {}, {delay: 3000, duration: 5500 }); Here the notification is fired after a 3000ms delay and the notification is spread among the receiving browsers during a 5500 interval. Using a scheduled notification var date = new Date( "December 17, 2013 03:24:00" ); ice.push.notifiy('a-group', {}, {at: date.getTime(), duration: 5500 }); Here the notification is fired at the specified time and the notification is spread among the receiving browsers during a 5500 interval.
        Mircea Toma made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Fix Version/s 4.0 [ 11383 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Mircea Toma
            Reporter:
            Ted Goddard
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: