[ https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14136267#comment-14136267 ]
Gerhard Petracek commented on EXTCDI-316: ----------------------------------------- #1 if your view-state leaks, it's the first indication that your approach is just not correct for jsf. #2 codi doesn't support multiple logical pages per physical page (per default). however, you can provide your own approach with a custom org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.spi.WindowHandler #3 the number of windows (per user-session) is restricted by WindowContextConfig#getMaxWindowContextCount - per default 64 windows per session are allowed. -> the eldest window in the session gets closed to get a free slot for the new window. you can change this default (just provide a specialized WindowContextConfig or implement a custom WindowContextQuotaHandler). > 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 > Original Estimate: 72h > Remaining Estimate: 72h > > 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 issue 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)