Details
Description
Using the Auction monitor, I noticed an overhead of addGroupMember invocation. Basically, on every clock-tick the a request for auction.jsf is send out. Handling this request causes the following logic to be executed in the BridgeSetup class:
public void processEvent(SystemEvent event) throws AbortProcessingException {
...
if (EnvUtils.isICEpushPresent()) {
SessionViewManager.addView(context, viewID);
...
}
...
The addView method of SessionViewManager is as follows:
public static String addView(FacesContext context, String id) {
PushContext pushContext = getPushContext(context);
State state = getState(context);
state.viewIDs.add(id);
pushContext.addGroupMember(state.groupName, id);
Iterator i = state.groups.iterator();
while (i.hasNext()) {
pushContext.addGroupMember((String) i.next(), id);
}
return id;
}
Basically, this causes the addGroupMember to be invoked for the JSessionID as well as all groups used and defined by the application. The invocations are identical every clock tick, showing the overhead. This gets worse when EPS is in play as well, because of the JMS communication.
SessionViewManager has an inner class properly called State. Maybe we should use the information contained in this class to optimize.
public void processEvent(SystemEvent event) throws AbortProcessingException {
...
if (EnvUtils.isICEpushPresent()) {
SessionViewManager.addView(context, viewID);
...
}
...
The addView method of SessionViewManager is as follows:
public static String addView(FacesContext context, String id) {
PushContext pushContext = getPushContext(context);
State state = getState(context);
state.viewIDs.add(id);
pushContext.addGroupMember(state.groupName, id);
Iterator i = state.groups.iterator();
while (i.hasNext()) {
pushContext.addGroupMember((String) i.next(), id);
}
return id;
}
Basically, this causes the addGroupMember to be invoked for the JSessionID as well as all groups used and defined by the application. The invocations are identical every clock tick, showing the overhead. This gets worse when EPS is in play as well, because of the JMS communication.
SessionViewManager has an inner class properly called State. Maybe we should use the information contained in this class to optimize.
Activity
Jack Van Ooststroom
created issue -
Ken Fyten
made changes -
Field | Original Value | New Value |
---|---|---|
Salesforce Case | [] | |
Fix Version/s | 2.0.0 [ 10230 ] | |
Assignee | Jack van Ooststroom [ jack.van.ooststroom ] |
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #23157 | Thu Nov 18 09:19:17 MST 2010 | jack.van.ooststroom | Fixed JIRA |
Files Changed | ||||
MODIFY
/icefaces2/trunk/icefaces/core/src/main/java/org/icefaces/impl/push/SessionViewManager.java
|
Jack Van Ooststroom
made changes -
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Ken Fyten
made changes -
Status | Resolved [ 5 ] | Closed [ 6 ] |
PushRenderer should remove (on Session timeout) all PUSHIDs managed by the ICEfaces PushRenderer).