Details
-
Type:
New Feature
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 2.0-Alpha3
-
Fix Version/s: None
-
Component/s: JavaScript Client
-
Labels:None
-
Environment:ICEpush, ICEfaces
Description
In particular, JSF is not thread-safe under concurrent requests from the same user.
To guard against this, ICEfaces notifications can be queued.
Activity
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 2.0.0 [ 10233 ] |
Investigation into HTML5 postMessage shows that it does not help with cross-window messaging for this feature or for propagation of Ajax Push notifications. postMessage requires a browser "window" reference, but that reference can be obtained only if the window is opened via JavaScript.
However, it appears that HTML5 storage has a listener API that may serve in place of the cookie technique we are currently using.
HTML5 storage listener (below) verified on Safari, Chrome, Firefox 4, and Opera. Not supported on Firefox 3.6 or IE 8. This can be used as an efficient low-latency cross-window notification mechanism on supported browsers.
<html>
<body>
<div id="outputdiv">
</div>
<input type="button" value="ping"
onclick="localStorage.setItem('org.icefaces.notify', (new Date().getMilliseconds()));" >
<script>
window.addEventListener('storage', storageListener, false);
function storageListener(evt) {
if (evt.key == "org.icefaces.notify")
}
</script>
</body>
</html>
ICEpush can be configured for queued notification (this is an optional feature;
you may not need it if you know your server-side framework is thread-safe).
With queued notification on (set queued = true):
ice.push.register(pushID, callback, queued)
If you receive a notification callback, you have exclusivity: no other pending
notifications will be sent to queued=true push clients until you call
ice.push.releaseNotifications()
Also:
ice.push.lockNotifications()
ice.push.lockNotifications(callback)
Note that these may be difficult to use depending on the framework. (The internals
of this locking callback are handled for you if queued=true.)
We cannot actually block the calling thread in JavaScript, so the way to implement
this appears to be through a callback that is invoked when the lock is acquired.
This can be implemented similarly to the master election mechanism for connection
ownership, but one difference is that the notification lock is often unheld (so spin locks
on a cookie may work).
As an example of the difficulty in applying this for JSF, we would need to suspend the
XMLHttpRequest triggered by client-side event processing and resume it in a callback.
One option is to also allow the no-arg call that indicates that the caller will accept the lock
if it can be provided immediately:
ice.push.lockNotifications()
This does not protect a currently active notification, but does protect the caller
against subsequent well-behaved notifications (those using the callback).
It is not essential to implement an actual queue: since contention for the lock will be relatively rare, it is sufficient that any callers waiting for the lock have a equal chance of acquiring it.
The following code attempts to analyze the threading behavior of the storage listener callback. On Safari and Firefox, the event listeners appear to be invoked in series, while on Chrome, they appear to be invoked in parallel. In all cases, the storage "set" call returns before the event listeners are invoked.
<html>
<body>
<div id="localdiv">
</div>
<div id="outputdiv">
</div>
<input type="button" value="ping"
onclick="localStorage.setItem('org.icefaces.notify',
(new Date().getTime())); document.getElementById('localdiv').innerHTML =
(new Date().getTime());" >
<div id="busydiv">
</div>
<script>
window.addEventListener('storage', storageListener, false);
function storageListener(evt) {
if (evt.key == "org.icefaces.notify") {
var j=0,i=0;
for (i=0;i<=50000;i++)
document.getElementById("outputdiv").innerHTML = evt.newValue + " " + ((new Date()).getTime() - evt.newValue);
}
}
</script>
</body>
</html>
| Salesforce Case | [] | |
| Fix Version/s | 2.1 [ 10259 ] | |
| Fix Version/s | 2.0.0 [ 10233 ] |
The important idea is multi-window notification using persistent storage.
| Assignee | Mircea Toma [ mircea.toma ] |
On the BlackBerry console, the following is seen repeatedly, likely due to ICEpush cookie polling. This is causing power consumption on the device without need as it can only display a single window at a time.
[0.0] start JSCmdGetCookieString
[0.0] end JSCmdGetCookieString
The inter-window notification mechanism using HTML5 local storage was carried as work under PUSH-136 issue.
| Assignee | Mircea Toma [ mircea.toma ] | Ted Goddard [ ted.goddard ] |
| Salesforce Case | [] | |
| Fix Version/s | 2.1 [ 10259 ] | |
| Assignee | Ted Goddard [ ted.goddard ] |
| Assignee | Jack Van Ooststroom [ jack.van.ooststroom ] |
| Fix Version/s | 3.4 [ 10971 ] |
| Component/s | Push Library [ 10044 ] | |
| Component/s | Push Server [ 10043 ] |
| Component/s | Push Server [ 10043 ] | |
| Component/s | Push Library [ 10044 ] |
| Assignee | Jack Van Ooststroom [ jack.van.ooststroom ] |
This JIRA was mistakenly edited instead of the newly created PUSH-268 JIRA.
| Fix Version/s | 3.4 [ 10971 ] |
Push-driven updates and user-driven updates in the same window will be automatically queued by JSF, the conflict occurs between push-driven or user-driven updates in distinct windows.
Another way to implement this is to provide a token-passing API that provides exclusivity to the caller.