Nuno G. de M created EXTCDI-316:
-----------------------------------
Summary: Close window context view leakge - JSF 2.1 Multiple
Iframes per page
Key: EXTCDI-316
URL: https://issues.apache.org/jira/browse/EXTCDI-316
Project: MyFaces CODI
Issue Type: Bug
Components: Core
Affects Versions: 1.0.3
Environment: Oracle GlassFish Server 3.1.2.5 (build 2), jdk1.6.0_45
Reporter: Nuno G. de M
Hi, and thank you for your support.
First, I would just like to stat that I am unsure if the "issue" detected in
our application is a real within CODI, or if it is we that are misusing the
framework. Therefore, I would be happy to get your input on the issue I am
about to detail.
ISSUE SUMMARY:
- we have a ui architecture comprised by several Iframes within a main page,
where each iframe has its own CODI window context. After several clicks
replacing the content that of a targetIfram by new content, we were having CODI
view context leakage as well as JSF view state leakage.
ISSUE DETAILS:
For historical as well performance reasons reasons, we have a UI that is
composed into several IFrames within a parent portal iframe. This decomposing
of the view into sub-views means the JSF context to serialize-deserialize per
iframe/.xhtml present in the UI is smaller. As opposed to a single big-ui view
state.
An overview of the core iframes invovled would be:
(1) window.top - Contains the Header and a left-side navigation menu
(2) window.top.contentIfram - Iframe Contains your typical page conent (.xhtml)
(3) window.top.footer - iframe containing a dynamic footer (its own .xhtml)
(4) wintow.top.applet - Iframe that includes an applet
(5) window.top.special - an auxiliary .xhtml that complements the applet data
(6) window.top.clean - iframe that contains an .xhtml to do CODI window context
and JSF sever state cleanup (created to deal with the issue being explained
here)
The BUG in view navigation is the following:
Each time the user interacts with the UI, e.g by clicing on an menu command
button, or on a applet view element, prompting for a new .xhtml view to be
loaded and replace the old .xhtml loaded on a target iframe we leak both a JSF
and CODI window context.
Our steps are the following:
(1) we change the src of the iframe to point to the new view to be loaded
e.g iframe.src = 'urlTonewPageToBeLoaded.xhtml?requestViewParameters'
In this request we do not inclode the old windowId of the iframe being
replaced. Meaning codi will have to create a new view ID for this new page load.
(2) We also trigger an ajax request to server to have the old codi window
context being closed.
Intially here did:
(2.1)WindowContext wContext =
windowContextManager.getWindowContext('windowIdToClose);
wContext.close()
It turns out that as we did these two steps we had two leakages.
After about 64 clicks on the applet, if we interatcted with views that the
applet had been loading we would have no issues. If we clicked on some of the
older views that had been loaded after the login and not interacted with since
then (e.g. the footer) we would have a view timeout exception.
This happened because with each new iframe.src='newView', CODI was not cleaning
up its window context map, namely the following line:
this.windowContextMap.remove(editableWindowContext.getId());
is not executed during a WindowContext.close().
So despite our class to close the window context, the map would continue to
hold the view just closed. After 64 clicks the view uffer of CODI would be
totally populated, and each new click was destroying the one of the least
recently used views. This could be the main menu, this could be the page
content or this could be the footer.
To address this issue, we had to start injecting the
EditableWindowContextManager, and use its close API.
So the procedure for closing a CODI window context avoiding CODI view leakge
turned into a :
Map<String, EditableWindowContext> existingContextIds =
getExistingContextIds();
windowContextManager.closeWindowContext(windowIdOfContextToClose);
Finally, there was still one last view leakge to address.
Even when we use the
windowContextManager.closeWindowContext(windowIdOfContextToClose), the JSF view
state associate to this view still exists in the JSF view map.
JSF-core (e.g majorra) seems to have a limit of 15 views within this LRU
logical map.
So once we stopped leaking views in CODI, we still had to tackle the leakage in
JSF. Meaning, when we close a CODI window context, we need to the
javax.views.state string to access the JSF map of logical views and remove
them.
Object sessionObj = externalContext.getSession(false);
synchronized (sessionObj) {
Map logicalMap = (Map) externalContext.getSessionMap().get(LOGICAL_VIEW_MAP);
Map actualMap = (Map) logicalMap.get(idInLogicalMap);
actualMap.clear();
// remove the leaked view from the LRU map of logical
views
logicalMap.remove(idInLogicalMap);
}
------
Naturally, an application should normally not have to dig deep into framework
code. One of the two is for sure true:
- either we are misusing CODI to manage our views
- or CODI has an issue
Thanks in advance for any input on this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
