ICEpush
  1. ICEpush
  2. PUSH-260

Accurate cleanup of PushIDs across multiple windows and page reloads

    Details

    • Assignee Priority:
      P1

      Description

      There are cases where pushIDs are not cleaned up, possibly due to browser bugs. A different strategy could yield accurate cleanup even under poor browser behavior.

        Activity

        Hide
        Ted Goddard added a comment -

        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.

        Show
        Ted Goddard added a comment - 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.
        Hide
        Steve Maryka added a comment -

        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.

        Show
        Steve Maryka added a comment - 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.
        Hide
        Ted Goddard added a comment -
        • 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.

        Show
        Ted Goddard added a comment - 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.
        Hide
        Mircea Toma added a comment - - edited

        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.

        Show
        Mircea Toma added a comment - - edited 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.
        Hide
        Mircea Toma added a comment -

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

        Show
        Mircea Toma added a comment - Implemented pushID expiry mechanism based on the measured largest in-between notifications interval.
        Hide
        Ted Goddard added a comment -

        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.

        Show
        Ted Goddard added a comment - 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.
        Hide
        Ted Goddard added a comment -

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

        Show
        Ted Goddard added a comment - 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/>

          People

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

            Dates

            • Created:
              Updated:
              Resolved: