10

My application uses JSF 2.1 with PrimeFaces. Recently, very high CPU Utilization was observed because of some stuck threads. The stuck thread dump for all stuck threads pointed to javax.faces.component.UIComponent.popComponentFromEL like below:

javax.faces.component.UIComponent.popComponentFromEL(UIComponent.java:1934)
javax.faces.component.UIComponent.visitTree(UIComponent.java:1633)
javax.faces.component.UIComponent.visitTree(UIComponent.java:1623)
org.primefaces.component.api.UIData.visitRows(UIData.java:741)
org.primefaces.component.api.UIData.visitTree(UIData.java:656)
javax.faces.component.UIComponent.visitTree(UIComponent.java:1623)
org.primefaces.component.accordionpanel.AccordionPanel.visitTree(AccordionPanel.java:371)
javax.faces.component.UIComponent.visitTree(UIComponent.java:1623)
javax.faces.component.UIComponent.visitTree(UIComponent.java:1623)
javax.faces.component.UIComponent.visitTree(UIComponent.java:1623)
javax.faces.component.UIForm.visitTree(UIForm.java:371)
javax.faces.component.UIComponent.visitTree(UIComponent.java:1623)
javax.faces.component.UIComponent.visitTree(UIComponent.java:1623)
javax.faces.component.UIComponent.visitTree(UIComponent.java:1623)
javax.faces.component.UIComponent.visitTree(UIComponent.java:1623)
com.sun.faces.application.view.StateManagementStrategyImpl.findComponent(StateManagementStrategyImpl.java:440)
com.sun.faces.application.view.StateManagementStrategyImpl.restoreDynamicRemove(StateManagementStrategyImpl.java:412)
com.sun.faces.application.view.StateManagementStrategyImpl.restoreDynamicActions(StateManagementStrategyImpl.java:317)
com.sun.faces.application.view.StateManagementStrategyImpl.restoreView(StateManagementStrategyImpl.java:281)
com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:188)
com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123)
com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:453)
com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:142)
com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:192)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:77)
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
com.ultimatix.bgc.framework.GBGCSessionControllerFilter.doFilter(GBGCSessionControllerFilter.java:90)
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
com.ultimatix.framework.jsf.util.ForcedLoginFilter.doFilter(ForcedLoginFilter.java:505)
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
com.ultimatix.framework.jsf.util.IndexFilter.doFilter(IndexFilter.java:338)
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
com.ultimatix.framework.jsf.util.SecurityInterceptor.doFilter(SecurityInterceptor.java:40)
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3715)
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)
weblogic.work.ExecuteThread.run(ExecuteThread.java:176)

How is this caused and how can I solve it?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
Viniti
  • 125
  • 2
  • 9
  • What did you try to achieve? Some code? – Markus May 07 '15 at 06:48
  • The real problem is probably invocations to: UIComponent.popComponentFromEL ...which seems to never return. – Viniti May 07 '15 at 06:51
  • You forgot to tell the versions. You should know that version information is very important to lookup the right source code lines based on line numbers in the stack trace. In any case, have you tried the latest just to see if it isn't already fixed in a newer version? – BalusC May 07 '15 at 07:05
  • I am using primefaces3.4.2, jsf-api-2.1.7 and jsf-impl-2.1.7 – Viniti May 07 '15 at 07:19
  • Those are old. Try at least the latest jsf 2.1.x – Kukeltje May 07 '15 at 09:12
  • I tried using mojarra 2.1.29, but it is having some issues with ajax requests, the latest that i could use was mojarra 2.1.17..but i am not sure whether this version will help...as the stuck threads comes only in Production environment when load is high – Viniti May 07 '15 at 09:31
  • @balusc we are having the same issue, but we are not using any bindings in our code. The environment details : weblogic 12.1.3.0, Liferay 6.2 EE, Primefaces 5.1, Jsf Mojarra 2.2.14. This is happening under heavy load (when security scans are running). Any help would be much appreciated – sk85 Jun 27 '17 at 17:56

1 Answers1

7

As per Mojarra issue 2722 this will happen when you incorrectly bind component instances to a bean property of a managed bean which is not request scoped, but in a broader scope.

<x:someComponent binding="#{viewOrSessionOrApplicationScopedBean.component}" />

Fix the code accordingly that this never happens. Components are inherently request scoped and may absolutely not be shared across multiple requests. See also JSF 2.0 specitication chapter 3.1.5:

3.1.5 Component Bindings

...

Component bindings are often used in conjunction with JavaBeans that are dynamically instantiated via the Managed Bean Creation facility (see Section 5.8.1 “VariableResolver and the Default VariableResolver”). It is strongly recommend that application developers place managed beans that are pointed at by component binding expressions in “request” scope. This is because placing it in session or application scope would require thread-safety, since UIComponent instances depends on running inside of a single thread. There are also potentially negative impacts on memory management when placing a component binding in “session” scope.

See also:

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • we are having the issue, but we are not using any bindings in our code. The environment details : weblogic 12.1.3.0, Liferay 6.2 EE, Primefaces 5.1, Jsf Mojarra 2.2.14. This is happening under heavy load (when security scans are running). Any help would be much appreciated. – sk85 Jun 23 '17 at 20:14
  • @BalusC, how can I track/log that from which component at application level (page/component) is this thread getting stuck? – Asif Arshad Feb 06 '18 at 09:49