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.

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

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

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.

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.

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.

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.