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

        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.
        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.
        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.
        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.
        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.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: