Details
-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0-Alpha1
-
Fix Version/s: 2.0-Alpha3, 2.0.0
-
Component/s: Framework
-
Labels:None
-
Environment:ICEfaces 2.0
Description
The current mechanism of specifying com.icesoft.faces.synchronousUpdate true/false per web application is too coarse: if push interaction is not required during a certain phase of the application, the blocking connection should not be established.
To optimize this, the blocking connection should be established only when needed: only when the current view has been added to a render group and is capable of receiving push updates.
For instance, if PushRender.addCurrentSession() is called prior to page rendering, the bridge must subsequently be configured to initiate the blocking connection for that user.
If a session has been added to a render group, in order to shutdown the blocking connection when not needed, the session will be removed from the render group when all active views have been closed. Therefore, the application must add each view prior to rendering (this is a common application practice since views are typically added independently).
This can be configured:
org.icefaces.push.establish="lazy"|always"|"never" ("lazy" is the default)
With "lazy" initialization, the push connection is established only when a given session or view has been added to a render group. With "always" establishment and "never" establishment, the behavior is the same as synchronousUpdate "false" and "true" respectively.
Issue Links
- is duplicated by
-
ICE-2102
Add granularity to synchronous vs asynchronous modes
-
- Closed
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Will this feature also dynamically disable push when a view that was previously added to a render group is removed from the render group?
That's a good point. Push should be enabled on the page if the page is possible to update via push: in other words, the session is a member of a push group at the time the page is rendered. So, removing a session from all push groups, should result in push being disabled on that page.
Laziness report from examination of ICEfaces 2.0 "basic" demo including icepush.jar but using no push features:
page includes
<script src='code.icepush.jsf?a662406917' type='text/javascript'></script>
ice.push.register(['6564709390015864202:-7640438167776689860']
Blocking connection started:
POST /basic/listen.icepush.jsf HTTP/1.1
and is continually established with server-side heartbeat.
Non-ICEfaces page do not contain any ICEfaces or ICEpush references.
It is likely that the current session is a member of a render group for "session expired" notification, but this group should only be joined if push is otherwise used in the application, or "session expired" is explicitly configured (such as on the ice:config tag).
Full laziness should likely even omit the icepush javascript from the page, but this is worth discussion in the next core meeting.
Introduced LazyPushManager to keep track of views that are push enabled. The UIOutput responsible for rendering the ICEpush wiring will dynamically render the JS code only when a view is registered with PushRenderer. The view state key generated by BridgeSetup is now properly reused by PushRenderer to avoid a stack overflow.
This issue might have been fixed by the resolution of
PUSH-30.