Refactored internal communication between PushGroupManager and BlockingConnectionServer. Introduced the concept of confirmation for the received notifications. Implemented notification queue to make sure the notifications are properly serialized and buffered when needed. Moved browser request timeout mechanism in BlockingConnectionServer that lets the PushGroupManager know when notifications were not received.

Introduced parameter that can be used to configure the notification queue size:

org.icepush.notificationQueueSize (defaults to 1000)

Introduced also parameter that can be used to configure the time to wait (in milliseconds) for the notification confirmation from the browser:

org.icepush.connectionRecreationTimeout (default to 500)

The SessionViewManager in ICEfaces is calling LocalPushGroupManager.addMember(group, id) to add the current view (as pushID) to the session group. This occurs on each JSF lifecycle. Everything is normal up until now. The problem is triggered when LocalPushGroupManager.addMember method is scanning the groups for expiry. Every time a page is rendered or updated a scan for expiry is executed, which is not what we want. The scanning should be done only after a notification was broadcasted and the notification confirmations are received back. This way the server has a chance to touch the groups that are still active and only after that expire the ones inactive.

The fix applied just removes the LocalPushGroupManager.scanForExpiry call in LocalPushGroupManager.addMember method.