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