[jira] [Comment Edited] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page

["Nuno G. de M (JIRA)" <de...@myfaces.apache.org>]

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

Nuno G. de M edited comment on EXTCDI-316 at 9/17/14 6:40 AM:
--------------------------------------------------------------

#1 I am not diening your point.
However, if it leaks it is not as straight-forward stated in your post that  the issue is on our apporach.

If when we replace an iframe content from xhtml by another xhtml, in the process creating a new CODI window context for the new xhtml to be  loaded and we get a leak of the cold WindowId that we swapped out - despite the fact that we have explicitly used CODI that get a hold of the old window context and have it closed, the issue could actually be on the CODI framework itself, who provides an API for closing windows that is leaking.

And indeed, concerning this point, we are able to stop leaking CODI window contexts into the LRU buffer map of codi, if we go-around and use the editbale window context manager API to trigger the closing of the window context.

Nevertheless,  if you are well aware of the fact that by doing WindowContext.close() the window continues within the LRU map of CODI windows, ant that this in fact the way the framework is supposed to work, than indeed we are misusing the framework. 


#2 Can you please provide some more input as to what is missing in current default implementation of the WindowHandler to support such a page design?

#3 I am aware of the fact that CODI "theoretically" supports by default 64 window contexts per default per user session.
And indeed we do not need more than 6 in a typical use case, because we close the old window context and open a new one.
But actually, there seems to be a huger gap between the 64 WindowCOntexts that feed into the CODI buffer with 64 LRU entries, and the JSF session map, which an LRU map that supports up to 15 logical views.
I have the impression that if you were to use more than 15 CODI window contexts, say 16, the 16th view state would have curshed the JSF Session Map from which the ServerSideSTate Helper of JSF tries to restore the view state.
One of the CODI window contexts view states would have been blown away.

Thanks for any further input.




was (Author: ngdem):
#1 I am not diening your point.
However, if it leaks it is not as straigt-forward as that that the issue is on our apporach.
If when we replace an iframe content from xhtml by another xhtml page creating a new CODI window context we get a leak, despite the fact that we explicitly take a hold of the window context and tell it to close, the issue could actually be on the CODI framework api we are using. And indeed we are able to stop leaking CODI window contexts into the LRU buffer map of codi, if we use the editbale window context manager API to trigger the closing of the window context.

But if you are are aware of the fact that by doing WindowContext.close() the window continues within the buffer of CODI windows, ant that is the way the framework is supposed to work, than indeed we are misusing the framework.


#2 Can you please provide some more input as to what is missing in current default implementation of the WindowHandler to support such a page design?

#3 I am aware of the fact that CODI "theoritecally" supports by default 64 window contexts per default per user session.
And indeed we do not need more than 6 in a typical use case, because we close the old window context and open a new one.
But actually, there seems to be a huger gap between the 64 WindowCOntexts that feed into the CODI buffer with 64 LRU entries, and the JSF session map, which an LRU map that supports up to 15 logical views.
I have the impression that if you were to use more than 15 CODI window contexts, say 16, the 16th view state would have curshed the JSF Session Map from which the ServerSideSTate Helper of JSF tries to restore the view state.
One of the CODI window contexts view states would have been blown away.

Thanks for any further input.



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