Fils collés à 100% utilisation CPU dans HashMap pendant JSF saveState()
nous avons un problème dans notre environnement de production, 4 Threads est à 100% D'utilisation CPU de la commande HTOP. Pour approfondir la question j'ai généré un dump de Thread afin de trouver quel thread est en train de manger le CPU.
Voici ce que j'ai trouvé. Les 4 threads ont la même trace de pile qui sont tous dans l'état RUNNABLE . Malheureusement je suis coincé à mon enquête puisque la trace de pile n'a aucune référence à mon code interne il est plus sur Côté Richfaces. Je pense que C'est la partie où JSF render une page.
la trace de la pile.
"ajp-0.0.0.0-8009-47" daemon prio=10 tid=0x00007fb8040af000 nid=0x172c runnable [0x00007fb8b3bf8000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.hash(HashMap.java:351)
at java.util.HashMap.putForCreate(HashMap.java:512)
at java.util.HashMap.putAllForCreate(HashMap.java:534)
at java.util.HashMap.<init>(HashMap.java:320)
at org.ajax4jsf.component.UIDataAdaptorBase.createChildStateCopy(UIDataAdaptorBase.java:894)
at org.ajax4jsf.component.UIDataAdaptorBase.saveState(UIDataAdaptorBase.java:1554)
at org.richfaces.component.UIDataTable.saveState(UIDataTable.java:181)
at org.richfaces.component.html.HtmlDataTable.saveState(HtmlDataTable.java:1361)
at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1103)
at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1119)
at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1119)
at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1119)
at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1119)
at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1119)
at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1119)
at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1119)
at org.ajax4jsf.component.AjaxViewRoot.processSaveState(AjaxViewRoot.java:751)
at org.ajax4jsf.application.AjaxStateManager.getComponentStateToSave(AjaxStateManager.java:179)
at org.ajax4jsf.application.AjaxStateManager.buildViewState(AjaxStateManager.java:515)
at org.ajax4jsf.application.AjaxStateManager$SeamStateManagerWrapper.saveView(AjaxStateManager.java:106)
at org.jboss.seam.jsf.SeamStateManager.saveView(SeamStateManager.java:89)
at org.ajax4jsf.application.AjaxStateManager.saveSerializedView(AjaxStateManager.java:470)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:615)
at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:100)
at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:176)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.josso.servlet.agent.GenericServletSSOAgentFilter.doFilter(GenericServletSSOAgentFilter.java:558)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73)
at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:206)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515)
at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:436)
at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:384)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:722)
une autre chose est, Est-ce qu'il y a un moyen que je puisse puiser dans la trace de la pile, disons que je voulais générer un logs pour que je puisse dire quelle page dans mon application Cette Trace de pile est générée? Ou peut-être que je peux utiliser un écouteur de phase?
Toute aide serait apprécier. Remercier.
j'utilise la couche 2.2, Richfaces 3.3.3 final, JSF 1.2.
2 réponses
Ce,
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.hash(HashMap.java:351)
at java.util.HashMap.putForCreate(HashMap.java:512)
at java.util.HashMap.putAllForCreate(HashMap.java:534)
at java.util.HashMap.<init>(HashMap.java:320)
et ceci,
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:446)
at java.util.HashMap.get(HashMap.java:405)
sont connus threadproblèmes de sécurité avec java.util.HashMap quand un fil invoque un get() tandis qu'un autre fil fait en même temps un put() . Le fil sera pendant le calcul du hachage puis coincé dans une boucle infinie . La solution technique à ce problème est d'utiliser une implémentation ConcurrentMap . Voir aussi a. O. this dzone article .
Cependant, dans votre cas particulier,
at java.util.HashMap.<init>(HashMap.java:320)
at org.ajax4jsf.component.UIDataAdaptorBase.createChildStateCopy(UIDataAdaptorBase.java:894)
at org.ajax4jsf.component.UIDataAdaptorBase.saveState(UIDataAdaptorBase.java:1554)
at org.richfaces.component.UIDataTable.saveState(UIDataTable.java:181)
at org.richfaces.component.html.HtmlDataTable.saveState(HtmlDataTable.java:1361)
at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1103)
ce problème semble se manifester lorsque l'état de votre composant <rich:dataTable> est sur le point d'être sauvé. Cela suggère à son tour que la même instance du composant est accessible par plusieurs threads. Ce n'est pas juste, la classe UIComponent est en premier lieu jamais conçu pour être threadsafe. Cela indique à son tour que l'instance composant en question n'est pas request scoped comme requis par la spécification JSF. Cela peut par exemple se produire lorsque vous utilisez binding pour lier le composant à une session scopée ou peut-être même une application scoped bean ou, pire, un champ statique.
<x:someComponent ... binding="#{nonRequestScopedBean.someComponent}">
vous devriez dans votre codebase chercher un tel composant et le corriger en conséquence en s'assurant que la fève est requête scoped, ou en utilisant une solution différente pour l'exigence / problème pour lequel vous avez pensé que l'utilisation de binding de cette façon serait la bonne solution.
voir aussi:
après une longue analyse, mon problème est résolu.
comme nous utilisons la version 2.1.7 de jsf , UI repeat implémentée en utilisant hashmap dans la version 2.1.7. par conséquent, lorsque nous utilisons le cpu répété imbriqué est élevé. j'ai remplacé l'ui repeat par JSTL pour chaque application qui fonctionne maintenant.
d'une autre façon aussi vous pouvez utiliser, vous devez changer la JSF 2.2.4 ou une VERSION plus récente.