[MOBI-193] Push stops in Android after chasing audio/video play link - ICEsoft JIRA Issue Tracker

Hide

Permalink

Steve Maryka added a comment - 16/Mar/12 2:33 PM

I have captured http traffic to the Android device with wireshark. Here is the exact scenario, using mediacast

Applications restarted, 2 clients connect - Android and desktop chrome
Audio captured and uploaded on Android
Push a photo from chrome - push is good
Select audio clip from carousel (NOTE: There is another problem here as this does not take to the audio page)
Select audio clip again - works this time
Play it using the play link
Hit back button when audio completes - Returns you to the audio page, but looks like there is network traffic at this point
Hit home button to go back to main page
Push another image from chrome - push does not work.

The traffic captured shows:

Heartbeat: ice.pushid=1gzlpyc4s%3Ab4k&ice.pushid=1gzlpyc4s%3Ab4m&ice.pushid=1gzlpyc4s%3Afen&ice.pushid=viprlr92 <noop/>
Heartbeat: <notified-pushids>viprlr92</notified-pushids>
Faces-request: <partial-response><changes><update id="j_idt17:_t18_carousel">... <-- The carousel update (good push)
Hearbeat: <-- does not contain <noop/>
GET image for carousel
Faces-request: 2000<?xml version='1.0' encoding='UTF-8'?><partial-response><changes><update id="javax.faces.ViewRoot">... <-- this is the bad button press. it seems to return the existing page.
GET /mediacast/javax.faces.resource/jsf.js.jsf?ln=javax.faces&v=1131669477 HTTP/1.1 <-- fetching JS
Hearbeat: <-- does not contain <noop/>
Faces-request <partial-response><changes><update id="toolbar"> <-- Second button press. This one works and returns the Viewer page
GET /mediacast/javax.faces.resource/aef90e68-e074-4d41-a4d1-c862518c6f13.jsf; <-- the audio file
GET /mediacast/javax.faces.resource/aef90e68-e074-4d41-a4d1-c862518c6f13.jsf;
GET /mediacast/javax.faces.resource/aef90e68-e074-4d41-a4d1-c862518c6f13.jsf;
GET /mediacast/javax.faces.resource/aef90e68-e074-4d41-a4d1-c862518c6f13.jsf;
GET /mediacast/javax.faces.resource/aef90e68-e074-4d41-a4d1-c862518c6f13.jsf;
Heartbeat <noop/>
Faces-request: <partial-response><changes><update id="toolbar"> <-- Home button pressed. Response includes home page.
Heartbeat <noop/> <-- should contain a notification
Heartbeat <noop/>

So the heartbeat continues but the notification never comes.

Show

Steve Maryka added a comment - 16/Mar/12 2:33 PM I have captured http traffic to the Android device with wireshark. Here is the exact scenario, using mediacast Applications restarted, 2 clients connect - Android and desktop chrome Audio captured and uploaded on Android Push a photo from chrome - push is good Select audio clip from carousel (NOTE: There is another problem here as this does not take to the audio page) Select audio clip again - works this time Play it using the play link Hit back button when audio completes - Returns you to the audio page, but looks like there is network traffic at this point Hit home button to go back to main page Push another image from chrome - push does not work. The traffic captured shows: Heartbeat: ice.pushid=1gzlpyc4s%3Ab4k&ice.pushid=1gzlpyc4s%3Ab4m&ice.pushid=1gzlpyc4s%3Afen&ice.pushid=viprlr92 <noop/> Heartbeat: <notified-pushids>viprlr92</notified-pushids> Faces-request: <partial-response><changes><update id="j_idt17:_t18_carousel">... <-- The carousel update (good push) Hearbeat: <-- does not contain <noop/> GET image for carousel Faces-request: 2000<?xml version='1.0' encoding='UTF-8'?><partial-response><changes><update id="javax.faces.ViewRoot">... <-- this is the bad button press. it seems to return the existing page. GET /mediacast/javax.faces.resource/jsf.js.jsf?ln=javax.faces&v=1131669477 HTTP/1.1 <-- fetching JS Hearbeat: <-- does not contain <noop/> Faces-request <partial-response><changes><update id="toolbar"> <-- Second button press. This one works and returns the Viewer page GET /mediacast/javax.faces.resource/aef90e68-e074-4d41-a4d1-c862518c6f13.jsf; <-- the audio file GET /mediacast/javax.faces.resource/aef90e68-e074-4d41-a4d1-c862518c6f13.jsf; GET /mediacast/javax.faces.resource/aef90e68-e074-4d41-a4d1-c862518c6f13.jsf; GET /mediacast/javax.faces.resource/aef90e68-e074-4d41-a4d1-c862518c6f13.jsf; GET /mediacast/javax.faces.resource/aef90e68-e074-4d41-a4d1-c862518c6f13.jsf; Heartbeat <noop/> Faces-request: <partial-response><changes><update id="toolbar"> <-- Home button pressed. Response includes home page. Heartbeat <noop/> <-- should contain a notification Heartbeat <noop/> So the heartbeat continues but the notification never comes.

Hide

Permalink

Ted Goddard added a comment - 25/Mar/13 4:19 PM

Adding a button to the page that prevents pushIDs from being cleared during onunload:

ice.setupPush('vgkhrkfa');

POST /mediacast/javax.faces.resource/listen.icepush.xml.jsf
Cookie: com.icesoft.user-agent=HyperBrowser/1.0; JSESSIONID=D3D49F70A9150E26876EA5D847DBF08B; com.icesoft.user-agent=HyperBrowser/1.0; ice.push.browser=1heq42673; com.icesoft.user-agent=HyperBrowser/1.0; ice.pushids=vxa54j65%20vxa54j68%20vgkhrkfa;
ice.pushid=vxa54j65&ice.pushid=vxa54j68&ice.pushid=vgkhrkfa

GET /mediacast/javax.faces.resource/43785373-60f3-4727-964d-64a3b2a64bed.jsf;jsessionid=D3D49F70A9150E26876EA5D847DBF08B
Cookie: com.icesoft.user-agent=HyperBrowser/1.0; JSESSIONID=D3D49F70A9150E26876EA5D847DBF08B; com.icesoft.user-agent=HyperBrowser/1.0; ice.push.browser=1heq42673; com.icesoft.user-agent=HyperBrowser/1.0; ice.pushids=vxa54j65%20vxa54j68%20vgkhrkfa;

GET /mediacast/javax.faces.resource/43785373-60f3-4727-964d-64a3b2a64bed.jsf;jsessionid=D3D49F70A9150E26876EA5D847DBF08B
User-Agent: stagefright/1.2 (Linux;Android 4.2.1)

POST /mediacast/javax.faces.resource/listen.icepush.xml.jsf
Cookie: com.icesoft.user-agent=HyperBrowser/1.0; JSESSIONID=D3D49F70A9150E26876EA5D847DBF08B; com.icesoft.user-agent=HyperBrowser/1.0; ice.push.browser=1heq42673; com.icesoft.user-agent=HyperBrowser/1.0; ice.pushids=vxa54j65%20vxa54j68%20vgkhrkfa;
ice.pushid=vxa54j65&ice.pushid=vxa54j68&ice.pushid=vgkhrkfa
X-Connection: close
X-Connection-reason: duplicate

(I was originally recording this traffic to analyze the problem; on the last test push appears to continue to function, so it may be due to the device sleeping in between, or just inconsistent testing on my part.)

Show

Ted Goddard added a comment - 25/Mar/13 4:19 PM Adding a button to the page that prevents pushIDs from being cleared during onunload: ice.setupPush('vgkhrkfa'); POST /mediacast/javax.faces.resource/listen.icepush.xml.jsf Cookie: com.icesoft.user-agent=HyperBrowser/1.0; JSESSIONID=D3D49F70A9150E26876EA5D847DBF08B; com.icesoft.user-agent=HyperBrowser/1.0; ice.push.browser=1heq42673; com.icesoft.user-agent=HyperBrowser/1.0; ice.pushids=vxa54j65%20vxa54j68%20vgkhrkfa; ice.pushid=vxa54j65&ice.pushid=vxa54j68&ice.pushid=vgkhrkfa GET /mediacast/javax.faces.resource/43785373-60f3-4727-964d-64a3b2a64bed.jsf;jsessionid=D3D49F70A9150E26876EA5D847DBF08B Cookie: com.icesoft.user-agent=HyperBrowser/1.0; JSESSIONID=D3D49F70A9150E26876EA5D847DBF08B; com.icesoft.user-agent=HyperBrowser/1.0; ice.push.browser=1heq42673; com.icesoft.user-agent=HyperBrowser/1.0; ice.pushids=vxa54j65%20vxa54j68%20vgkhrkfa; GET /mediacast/javax.faces.resource/43785373-60f3-4727-964d-64a3b2a64bed.jsf;jsessionid=D3D49F70A9150E26876EA5D847DBF08B User-Agent: stagefright/1.2 (Linux;Android 4.2.1) POST /mediacast/javax.faces.resource/listen.icepush.xml.jsf Cookie: com.icesoft.user-agent=HyperBrowser/1.0; JSESSIONID=D3D49F70A9150E26876EA5D847DBF08B; com.icesoft.user-agent=HyperBrowser/1.0; ice.push.browser=1heq42673; com.icesoft.user-agent=HyperBrowser/1.0; ice.pushids=vxa54j65%20vxa54j68%20vgkhrkfa; ice.pushid=vxa54j65&ice.pushid=vxa54j68&ice.pushid=vgkhrkfa X-Connection: close X-Connection-reason: duplicate POST /mediacast/javax.faces.resource/listen.icepush.xml.jsf Cookie: com.icesoft.user-agent=HyperBrowser/1.0; JSESSIONID=D3D49F70A9150E26876EA5D847DBF08B; com.icesoft.user-agent=HyperBrowser/1.0; ice.push.browser=1heq42673; com.icesoft.user-agent=HyperBrowser/1.0; ice.pushids=vxa54j65%20vxa54j68%20vgkhrkfa; ice.pushid=vxa54j65&ice.pushid=vxa54j68&ice.pushid=vgkhrkfa X-Connection: close X-Connection-reason: duplicate (I was originally recording this traffic to analyze the problem; on the last test push appears to continue to function, so it may be due to the device sleeping in between, or just inconsistent testing on my part.)

Hide

Permalink

Ted Goddard added a comment - 25/Mar/13 4:47 PM

Experimentation with an ICEpush feature that prevents the unload from clearing the cookies does seem to help, but unfortunately the container onPause() is invoked after the page is unloaded.

Show

Ted Goddard added a comment - 25/Mar/13 4:47 PM Experimentation with an ICEpush feature that prevents the unload from clearing the cookies does seem to help, but unfortunately the container onPause() is invoked after the page is unloaded.

Hide

Permalink

Ted Goddard added a comment - 25/Mar/13 5:16 PM

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.

Show

Ted Goddard added a comment - 25/Mar/13 5:16 PM 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.

Hide

Permalink

Ted Goddard added a comment - 25/Mar/13 5:26 PM

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 - 25/Mar/13 5:26 PM 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

Permalink

Ted Goddard added a comment - 01/May/13 3:04 PM

This is an important fix so should be considered for 1.3EE.

Show

Ted Goddard added a comment - 01/May/13 3:04 PM This is an important fix so should be considered for 1.3EE.

Push stops in Android after chasing audio/video play link

Details

Description

Attachments

Activity

People

Dates