Re: Performance issue with component bindings and Ajax requests
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
Re: Performance issue with component bindings and Ajax requests
On 20/08/2014 09:41, Marc Heinz wrote: 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. I am also interesting by this issue and ready to test a fix in the days to come. Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Issue with javax.faces.SEPARATOR_CHAR and commandLink
Hello all, We've come across an issue while trying to modify the javax.faces.SEPARATOR_CHAR - changing it to a non-colon character seems to break h:commandLink actions. For example, with the separator character set to a hyphen -, the following navigation does not work (the output link just triggers a refresh): f:view h:form h:commandLink id=link action=toLink.html h:outputText value=Link / /h:commandLink /h:form /f:view This can be observed in MyFaces 2.0.21, 2.1.15, and 2.2.4. A workaround is to enable the context parameter org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE, however that parameter has been removed in the 2.2 branch. (It's also not a particularly desirable workaround.) The issue here seems to stem from the oamSubmit.js script; in that file there is a call myfaces.oam.setHiddenInput(formName, formName + ':' + '_idcl', linkId); which explicitly passes uses a colon separator character. In HtmlRendendererUtils.getHiddenCommandLinkFieldname, however, we have return formInfo.getFormName() + UINamingContainer.getSeparatorChar (FacesContext.getCurrentInstance())+ HIDDEN_COMMANDLINK_FIELD_NAME; which will cause the wrong hidden field name to be searched, and the broken actions seen here. Is this a bug, or just an accepted limitation of javax.faces.SEPARATOR_CHAR use? Thanks for any feedback! Bill Lucy IBM RTP WebSphere wtl...@us.ibm.com
Re: Issue with javax.faces.SEPARATOR_CHAR and commandLink
Hi 2014-08-20 6:36 GMT-05:00 William Lucy wtl...@us.ibm.com: Hello all, We've come across an issue while trying to modify the javax.faces.SEPARATOR_CHAR - changing it to a non-colon character seems to break h:commandLink actions. For example, with the separator character set to a hyphen -, the following navigation does not work (the output link just triggers a refresh): f:view h:form h:commandLink id=link action=toLink.html h:outputText value=Link / /h:commandLink /h:form /f:view This can be observed in MyFaces 2.0.21, 2.1.15, and 2.2.4. A workaround is to enable the context parameter org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE, however that parameter has been removed in the 2.2 branch. (It's also not a particularly desirable workaround.) Yes, that's the reason why we remove it. It was legacy stuff from 1.1/1.2 and with 2.2 it is the right time to do a cleanup in the codebase. The issue here seems to stem from the oamSubmit.js script; in that file there is a call myfaces.oam.setHiddenInput(formName, formName + ':' + '_idcl', linkId); which explicitly passes uses a colon separator character. In HtmlRendendererUtils.getHiddenCommandLinkFieldname, however, we have return formInfo.getFormName() + UINamingContainer.getSeparatorChar (FacesContext.getCurrentInstance())+ HIDDEN_COMMANDLINK_FIELD_NAME; which will cause the wrong hidden field name to be searched, and the broken actions seen here. Is this a bug, or just an accepted limitation of javax.faces.SEPARATOR_CHAR use? Thanks for any feedback! It is a bug. We should not use UINamingContainer.getSeparatorChar(...) to render that hidden field and enforce ':' instead. The reason is the intention of use javax.faces.SEPARATOR_CHAR is to avoid the collision with css when you use the ':', but in this case the intention is to create a hidden field, with no real underlying component, so it is better to let ':' on the js file. Please create an issue in MyFaces issue tracker and I'll fix it on all affected branches. https://issues.apache.org/jira/browse/MYFACES regards, Leonardo Uribe Bill Lucy IBM RTP WebSphere wtl...@us.ibm.com
Re: Issue with javax.faces.SEPARATOR_CHAR and commandLink
Hi Leonardo, Thanks for the feedback. I've tested your suggestion, and that seems to work fine. JIRA issue opened at: https://issues.apache.org/jira/browse/MYFACES-3919 Regards, Bill Leonardo Uribe lu4...@gmail.com wrote on 08/20/2014 01:14:39 PM: From: Leonardo Uribe lu4...@gmail.com To: MyFaces Discussion users@myfaces.apache.org Date: 08/20/2014 01:15 PM Subject: Re: Issue with javax.faces.SEPARATOR_CHAR and commandLink Hi 2014-08-20 6:36 GMT-05:00 William Lucy wtl...@us.ibm.com: Hello all, We've come across an issue while trying to modify the javax.faces.SEPARATOR_CHAR - changing it to a non-colon character seems to break h:commandLink actions. For example, with the separator character set to a hyphen -, the following navigation does not work (the output link just triggers a refresh): f:view h:form h:commandLink id=link action=toLink.html h:outputText value=Link / /h:commandLink /h:form /f:view This can be observed in MyFaces 2.0.21, 2.1.15, and 2.2.4. A workaround is to enable the context parameter org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE, however that parameter has been removed in the 2.2 branch. (It's also not a particularly desirable workaround.) Yes, that's the reason why we remove it. It was legacy stuff from 1.1/1.2 and with 2.2 it is the right time to do a cleanup in the codebase. The issue here seems to stem from the oamSubmit.js script; in that file there is a call myfaces.oam.setHiddenInput(formName, formName + ':' + '_idcl', linkId); which explicitly passes uses a colon separator character. In HtmlRendendererUtils.getHiddenCommandLinkFieldname, however, we have return formInfo.getFormName() + UINamingContainer.getSeparatorChar (FacesContext.getCurrentInstance())+ HIDDEN_COMMANDLINK_FIELD_NAME; which will cause the wrong hidden field name to be searched, and the broken actions seen here. Is this a bug, or just an accepted limitation of javax.faces.SEPARATOR_CHAR use? Thanks for any feedback! It is a bug. We should not use UINamingContainer.getSeparatorChar(...) to render that hidden field and enforce ':' instead. The reason is the intention of use javax.faces.SEPARATOR_CHAR is to avoid the collision with css when you use the ':', but in this case the intention is to create a hidden field, with no real underlying component, so it is better to let ':'on the js file. Please create an issue in MyFaces issue tracker and I'll fix it on all affected branches. https://issues.apache.org/jira/browse/MYFACES regards, Leonardo Uribe Bill Lucy IBM RTP WebSphere wtl...@us.ibm.com
