Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 4.0.BETA, EE-4.0.0.GA
-
Fix Version/s: 4.0.BETA, 4.0, EE-3.3.0.GA_P04
-
Component/s: Push Library
-
Labels:None
-
Environment:Tomcat 7, Showcase, Firefox
-
Assignee Priority:P1
Description
The blocking connection breaks after a few <noop /> responses. In order replicate this issue follow these steps:
* Deploy showcase to Tomcat
* Access the application in a browser
* Navigate to ace:progressBar -> Push
* Click on the "play" button
* Once you see "Progress completed" after a few <noop /> responses (seems to be 3) the blocking connection is severed.
This seems to be happening from the client side.
* Deploy showcase to Tomcat
* Access the application in a browser
* Navigate to ace:progressBar -> Push
* Click on the "play" button
* Once you see "Progress completed" after a few <noop /> responses (seems to be 3) the blocking connection is severed.
This seems to be happening from the client side.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Re-implemented pushId expiry mechanism. The mechanism relies on local storage events to communicate with the opened windows. This way it can verify what pushIDs are used by the windows. The pushIds unconfirmed as being still in used are expired/discarded.
Show
Mircea Toma
added a comment - Re-implemented pushId expiry mechanism. The mechanism relies on local storage events to communicate with the opened windows. This way it can verify what pushIDs are used by the windows. The pushIds unconfirmed as being still in used are expired/discarded.
No, no server changes required. The pushID expiry mechanism stops the blocking connection in this case. The mechanism is implemented all on the client.