Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Discussion" <users@myfaces.apache.org>
Received-SPF: pass (athena.apache.org: domain of mhz4248@gmail.com designates
 74.125.82.67 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABujnVe6W1NW=6Aub88PF9CsMR6bKKidvXR9j7+6df5BwL6h1g@mail.gmail.com>
References: 
 <CAGhBU9g01pYVN2rx_XgCNHsAFeXsWa3un7-2zxjrH3c+Ehu1xg@mail.gmail.com>
	<CABujnVe6W1NW=6Aub88PF9CsMR6bKKidvXR9j7+6df5BwL6h1g@mail.gmail.com>
Date: Wed, 20 Aug 2014 09:41:57 +0200
Message-ID: 
 <CAGhBU9jw1t7yA1U0SqMmY20OB26kd8+6d+atR6mx1jzhvGvZgQ@mail.gmail.com>
Subject: Re: Performance issue with component bindings and Ajax requests
From: Marc Heinz <mhz4248@gmail.com>
To: MyFaces Discussion <users@myfaces.apache.org>
Content-Type: multipart/alternative; boundary=001a1136b4fa18f54805010abdac

--001a1136b4fa18f54805010abdac
Content-Type: text/plain; charset=UTF-8

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 <lu4242@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 <mhz4248@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
>

--001a1136b4fa18f54805010abdac--