Thanks for the quick answer! We tried disabling PSS but this actually broke several other things, so we would prefer not to touch it right now.
Setting the flag "org.apache.myfaces.REMOVING_COMPONENTS_BUILD" however seems to do the trick... (we though about using it before but we were unsure about the possible implications). I've created an issue as suggested: https://issues.apache.org/jira/browse/MYFACES-3918 I will report any possible regression we find there, and I will test again when a fix becomes available. Once again, thanks a lot for the reactivity. Marc On Tue, Aug 19, 2014 at 8:42 PM, Leonardo Uribe <lu4...@gmail.com> wrote: > Hi > > The problem is the call to formRoot.getChildren().clear() activates > the listener for > PreRemoveFromViewEvent and that one register the removed components. Since > you are generating over and over components, after many requests that list > becomes big. > > I can imagine two solutions: > > 1. Disable PSS on the affected views, using > javax.faces.FULL_STATE_SAVING_VIEW_IDS param > > 2. Try to use this code on formRoot.getChildren().clear(); > > > facesContext.getAttributes.put("org.apache.myfaces.REMOVING_COMPONENTS_BUILD", > Boolean.TRUE); > formRoot.getChildren().clear(); > > facesContext.getAttributes.remove("org.apache.myfaces.REMOVING_COMPONENTS_BUILD"); > > That will avoid register the ids on the list, without side effects > (that I can imagine right now, > not 100% sure). > > Anyway, It is possible to find a solution changing the code in > DefaultFaceletsStateManagementStrategy, so the list keeps stable over time, > Please create an issue on MyFaces issue tracker: > > https://issues.apache.org/jira/browse/MYFACES > > regards, > > Leonardo Uribe > > 2014-08-19 8:12 GMT-05:00 Marc Heinz <mhz4...@gmail.com>: > > Hello everybody, > > > > We are currently encountering some performances issues with myfaces, and > we > > would really appreciate some help on the subject. > > > > We are generating forms to be filled by the user dynamically (through > > component binding) from a set of externally managed rules. Here is a > short > > overview: > > > > In our facelet: > > <h:panelGroup id="formRoot" binding="#{FormBean.formRoot}"/> > > > > Our backing bean: > > > > @RequestScoped > > public class FormBean { > > private boolean rebuildDone = false; > > private UIPanel formRoot; > > public UIPanel getFormRoot() { > > if (!rebuildDone) { > > rebuildForm(); > > } > > return formRoot; > > } > > public void setFormRoot(UIPanel formRoot) { > > // Ignore. > > } > > // Public method to rebuild the current form content in reaction to > > updates fired from Ajax managed components. > > public void rebuildForm() { > > if (formRoot == null) { > > formRoot = new UIPanel(); > > // The whole component tree is marked as transient. > > formRoot.setTransient(true); > > formRoot.setId("formRoot"); > > } > > > > // Clear the existing tree. > > formRoot.getChildren().clear(); > > > > // Start building the new component tree with formRoot as > parent. > > [...] > > } > > } > > > > We use Ajax extensively: all updates events are processed with > > AjaxBehaviorsListeners (wired on "onchange" client events). > > > > When a change is processed (during the INVOKE_APPLICATION phase), the > value > > is validated and the GUI is refreshed by calling the "rebuildForm()" > > method. The existing component tree will then be *cleared* by calling > > getChildren().clear() on the binding root component. It will be then > > rebuilt entirely (even though only a small subset of components are > usually > > affected). This is clearly inefficient, but this is some legacy code that > > we don't want to disturb unless strictly required. > > > > What we observed (with MyFaces 2.1.12 and the 2.1.16 r1618150 in trunk): > on > > all forms (but especially on forms with all lot of components) every Ajax > > request takes more time to complete than the previous one as long as we > > stay on the same view. On a form with ~70 fields, the turnaround time > > (measured with the Net panel of Firebug) goes from ~250ms (first request) > > to more than 1 second after ~15 update. > > > > After some profiling done with VisualVM, we pinpointed the location of > the > > latency to: > > > org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.handleDynamicAddedRemovedComponents(), > > accountable for > 70% of the processing time. On further inspection, it > > appears that a data structure, the list of removed client IDs > > (clientIdsRemoved), is growing endlessly across each request. > > > > We are not too sure where the problem is right now... Should we build the > > component tree only once during the RESTORE_VIEW phase and then update > it? > > (this seems hardly doable) Are we simply doing something in the wrong > > phase? Should I raise an issue on this? > > > > Any feedback would be most appreciated, > > > > Thanks, > > Marc >
