[prev in list] [next in list] [prev in thread] [next in thread] 

List:       myfaces-dev
Subject:    [jira] [Commented] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page
From:       "Nuno G. de M (JIRA)" <dev () myfaces ! apache ! org>
Date:       2014-09-19 16:05:34
Message-ID: JIRA.12741433.1410772660000.77946.1411142734433 () Atlassian ! JIRA
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin. \
system.issuetabpanels:comment-tabpanel&focusedCommentId=14140797#comment-14140797 ] 

Nuno G. de M commented on EXTCDI-316:
-------------------------------------

Hi Gerhard, thanks a lot for the feedback.

Concerning the viewScoped, I made a mistake, because I was thinking of the CODI scope \
"@WindowScoped" instead.

@windoIdToToDrop
That is actually what we do, but it is more tricky than that actually.
Before switching the iframe from the client Side, we ajax the server telling it to \
know about the windowId about to be swapped out. Finally, only on the onloadEvent of \
the new iframe can you actually really kill the "windowIdToDrop". The reason for this \
is that while you are loading a new window onto this iframe, if you use "comet-like" \
mechanism, the page can still be polling iformation from the server - and were youto \
wipeout the state until the view is replaced, you would a view expired exception.


So far the safest approach, would be, if it were possible, to keep the \
windowId/context of a given iframe constant throughout time as well as the \
corresponding JSF server side state key. That means using standard JSF navigation to \
swap the view of a given iframe. But this also implies that in order to do this, all \
the beans created within the scope of this windo iframe would have to be thrown away \
and replaced by the new beans for the view. This would be the ideal thing.





> 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)


[prev in list] [next in list] [prev in thread] [next in thread]