Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0-Alpha2
-
Fix Version/s: 2.0-Alpha3
-
Component/s: None
-
Labels:None
-
Environment:All
-
Workaround Exists:Yes
-
Workaround Description:
Description
This is an inherent problem with the current push protocol. To summarize imagine the following scenario:
a clientside application (GWT or pure JS) initializes and creates a push id. A group and callback are added to this id and a long poll is started. This poll will last X seconds (for simplicity lets assume 50s).
Now, 5 seconds later a new push id is needed with a new group and callback. The listen.icepush call is still outstanding (45 seconds to go) and it has already provided a list of push ids as post data. Thus the client will not receive any push updates to the newly created push id for another 45 seconds (when the next poll is started and the push id is listed in the post data of the next request.).
Not sure what the best solution to this problem is- two come to mind:
1.) kill the oustanding request if a new push id is registered to a callback
2.) update the protocol to not require the push ids as post data in the listen.icepush call.
a clientside application (GWT or pure JS) initializes and creates a push id. A group and callback are added to this id and a long poll is started. This poll will last X seconds (for simplicity lets assume 50s).
Now, 5 seconds later a new push id is needed with a new group and callback. The listen.icepush call is still outstanding (45 seconds to go) and it has already provided a list of push ids as post data. Thus the client will not receive any push updates to the newly created push id for another 45 seconds (when the next poll is started and the push id is listed in the post data of the next request.).
Not sure what the best solution to this problem is- two come to mind:
1.) kill the oustanding request if a new push id is registered to a callback
2.) update the protocol to not require the push ids as post data in the listen.icepush call.
Activity
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Ken Fyten [ ken.fyten ] |
| Assignee Priority | P2 | |
| Assignee | Ken Fyten [ ken.fyten ] | Mircea Toma [ mircea.toma ] |
| Fix Version/s | 1.0-Alpha3 [ 10224 ] | |
| Affects Version/s | 1.0-Alpha2 [ 10223 ] |
| Workaround Description | no workaround for this problem that I can think-off. | Create a global push group that all clients are automatically assigned to and push to this group before adding another callback. Pushing to this group will effectively mean that any outstanding long poll will be killed on the server side via a notification to the dummy group. |
| Workaround Exists | [Yes] |
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #20364 | Mon Jan 25 15:03:35 MST 2010 | mircea.toma | |
| Files Changed | ||||
MODIFY
/scratchpads/snowplow/core/src/main/javascript/connection.async.js
|
Good catch finding this issue! Quite subtle.
Show
Mircea Toma
added a comment - Good catch finding this issue! Quite subtle.
The solution I chose was to reset the blocking connection when new pushIDs are registered. This way the newly registered pushIDs are sent along to the server. The implementation for the fix is located on the client side. The blocking connection monitor is used to also detect when the list of pushIds has changed and reset the connection if needed.
Show
Mircea Toma
added a comment - The solution I chose was to reset the blocking connection when new pushIDs are registered. This way the newly registered pushIDs are sent along to the server. The implementation for the fix is located on the client side. The blocking connection monitor is used to also detect when the list of pushIds has changed and reset the connection if needed.
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Status | Resolved [ 5 ] | Closed [ 6 ] |
| Assignee Priority | P2 |
I found a possible workaround (though it is not very elegant.)