From MOBI-230:

It is likely necessary to define a new mechanism for clearing unused pushIDs. Disabling cleanup during onUnload allows push to continue functioning after the video is played, but it also results in an accumulation of old pushIDs. However, there are other cases where unused pushIDs accumulate, so an improved cleanup mechanism should be investigated.
Each browser window/tab has a set of pushIDs with active listeners. When a listen.icepush returns with a set of notifications, these need to be dispatched to the various browser windows via two mechanisms: local storage events and cookie polling. When a notification occurs (including a noop) each pushID in each window can have an associated timestamp so that the listening window can determine if a given pushID is still active. pushIDs with very old associated timestamps can be garbage collected.

In 1.3 EE testing on Jboss 7 installation, I was able to create a condition in the Android container using icemobilespring/notification page where an ajax push would occur, followed by a GCM notification for ever priority push that was generated. The problem persisted through a container restart, but stopped after the device was rebooted. If I cleared cookies in the container the problem would stop, until I caused a cloud push event. After this the double push would occur again with every push.

• when a listen response is received, store the current browser timestamp and the notified push IDs in the cookie/local storage.
• when a window polls the cookie for notified push IDs (or wakes up from the local storage update), it also stores its current push IDs and the timestamp in the cookie/local storage.
• when a listen response is received, remove any push IDs in the cookie/local storage if the timestamp exceeds the last timestamp by more than the poll interval

The end result is that the next listen request will only contain push IDs that are actually active in some window in the browser.

I am not entirely sure I understand the expiry algorithm. For one, the cookie based window notification mechanism the pool interval is 300ms. For the local storage the window notification is instant. Neither poll interval is realistic to be using it in the expiry calculation.

Maybe we could average the notification interval for a pushID, and then when there's no notification occurring after 2 to 3 times the measured interval we can expire the pushID.

Implemented pushID expiry mechanism based on the measured largest in-between notifications interval.

The key to this appears to be an actual determination of which pushIDs are in variables in the browser windows. If a browser window exists and references a pushID, that pushID should not be cleaned up based on any timeout.

When a listen response is received (either noop or a notification), the master window notifies all other windows of the response. Each window determines its own pushIDs and sets these in common storage with the current timestamp. If the master window sees pushIDs with timestamp older than two listen intervals (it can even store the timestamps of the listen responses rather than calculating an average) it means that the window holding those pushIDs did not respond recently. Those pushIDs can be cleaned up.

Recent testing on the iPhone from a single page HTML application shows what appears to be an accumulation of pushIDs. Additionally, the JavaScript console indicated that the connection was lost even though a response was received. I'll test further with an updated icepush.jar.

POST /push/listen.icepush HTTP/1.1
Host: labs.icesoft.com
Accept-Language: en-us
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 7_0 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11A465 Safari/9537.53
ice.push.sequence: 1
Accept: /
Referer: http://labs.icesoft.com/bridgeit/mobile.html
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
ice.push.window: 8117c
ice.push.browser: bhlyavwm8
Connection: keep-alive
Cookie: ice.connection.contextpath=http%3A%2F%2Flabs.icesoft.com%2Fpush%2F; ice.connection.lease=1380151919277; ice.connection.running=8117c%3Aacquired; ice.pushids=bhlyavwm8%3A1h4%20bhlyavwm8%3A1h5%20bhlyavwm8%3A1h8%20bhlyavwm8%3A1h9%20bhlyavwm8%3A1hg%20bhlyavwm8%3A1hh%20bhlyavwm8%3A1hi%20bhlyavwm8%3A1hj%20bhlyavwm8%3A1i6%20bhlyavwm8%3A1i7%20bhlyavwm8%3A1ic%20bhlyavwm8%3A1id%20bhlyavwm8%3A1ie%20bhlyavwm8%3A1if%20bhlyavwm8%3A1kn%20bhlyavwm8%3A1ko%20bhlyavwm8%3A1kx%20bhlyavwm8%3A1ky%20bhlyavwm8%3A1kz%20bhlyavwm8%3A1l0
Content-Length: 566
Origin: http://labs.icesoft.com
Accept-Encoding: gzip, deflate

ice.push.browser=bhlyavwm8&ice.pushid=bhlyavwm8%3A1h4&ice.pushid=bhlyavwm8%3A1h5&ice.pushid=bhlyavwm8%3A1h8&ice.pushid=bhlyavwm8%3A1h9&ice.pushid=bhlyavwm8%3A1hg&ice.pushid=bhlyavwm8%3A1hh&ice.pushid=bhlyavwm8%3A1hi&ice.pushid=bhlyavwm8%3A1hj&ice.pushid=bhlyavwm8%3A1i6&ice.pushid=bhlyavwm8%3A1i7&ice.pushid=bhlyavwm8%3A1ic&ice.pushid=bhlyavwm8%3A1id&ice.pushid=bhlyavwm8%3A1ie&ice.pushid=bhlyavwm8%3A1if&ice.pushid=bhlyavwm8%3A1kn&ice.pushid=bhlyavwm8%3A1ko&ice.pushid=bhlyavwm8%3A1kx&ice.pushid=bhlyavwm8%3A1ky&ice.pushid=bhlyavwm8%3A1kz&ice.pushid=bhlyavwm8%3A1l0

HTTP/1.1 200 OK
Date: Wed, 25 Sep 2013 23:31:04 GMT
Server: Apache-Coyote/1.1
Access-Control-Expose-Headers: ice.push.sequence,X-Connection,X-Connection-reason,X-Set-Window-Cookie,ice.push.heartbeatTimestamp
Access-Control-Allow-Headers: origin, ice.push.sequence, ice.push.window, ice.push.browser, content-type, ice.parkids, ice.notifyBack
Access-Control-Allow-Origin: https://labs.icesoft.com
Access-Control-Allow-Credentials: true
ice.push.sequence: 1680
X-Connection-reason: response timeout
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: must-revalidate
Pragma: no-cache
Expires: 0
Content-Type: text/xml;charset=UTF-8
Content-Length: 9
Connection: close

<noop/>