1. Accueil
  2. Question et réponse
  3. NPE intermittent pendant parseParameters dans la requête de Tomcat

NPE intermittent pendant parseParameters dans la requête de Tomcat

2010-06-22 5 views
1

Nous avons intermittet NPE au cours de parseParemeters dans org.apache.catalina.connector.Request. Plus les utilisateurs sont en ligne, plus cette NPE se produit. Après un redémarrage de JBoss, les NPE disparaissent pendant un moment. Dans les 24 heures, nous recevons entre un et plus de 400 de ces NPE. Peu importe le service appelé. Toute demande de service peut se terminer dans ce NPE.NPE intermittent pendant parseParameters dans la requête de Tomcat

 
java.lang.NullPointerException 
     at org.apache.catalina.connector.Request.parseParameters(Request.java:2517) 
     at org.apache.catalina.connector.Request.getParameterNames(Request.java:1102) 
     at org.apache.catalina.connector.Request.getParameterMap(Request.java:1082) 
     at org.apache.catalina.connector.RequestFacade.getParameterMap(RequestFacade.java:414) 
     at javax.servlet.ServletRequestWrapper.getParameterMap(ServletRequestWrapper.java:166) 
     at org.jboss.seam.mock.MockExternalContext.getRequestParameterValuesMap(MockExternalContext.java:307) 
     at org.jboss.seam.faces.Parameters.getRequestParameters(Parameters.java:61) 
     at org.jboss.seam.Component.injectParameters(Component.java:1586) 
     at org.jboss.seam.Component.inject(Component.java:1556) 
     at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:61) 
     at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) 
     at org.jboss.seam.transaction.TransactionInterceptor$1.work(TransactionInterceptor.java:97) 
     at org.jboss.seam.util.Work.workInTransaction(Work.java:61) 
     at org.jboss.seam.transaction.TransactionInterceptor.aroundInvoke(TransactionInterceptor.java:91) 
     at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) 
     at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) 
     at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) 
     at org.jboss.seam.security.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:163) 
     at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) 
     at ExceptionInterceptor.aroundInvoke(ExceptionInterceptor.java:51) 
     at sun.reflect.GeneratedMethodAccessor289.invoke(Unknown Source) 
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
     at java.lang.reflect.Method.invoke(Method.java:597) 
     at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) 
     at org.jboss.seam.intercept.Interceptor.aroundInvoke(Interceptor.java:187) 
     at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:72) 
     at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) 
     at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:185) 
     at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:103) 
     at TaskService_$$_javassist_seam_7.getNumberOfUpdatedTasks(TaskService_$$_javassist_seam_7.java) 
     at sun.reflect.GeneratedMethodAccessor319.invoke(Unknown Source) 
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
     at java.lang.reflect.Method.invoke(Method.java:597) 
     at org.jboss.seam.remoting.gwt.GWTToSeamAdapter.callWebRemoteMethod(GWTToSeamAdapter.java:100) 
     at org.jboss.seam.remoting.gwt.GWTService.RPC_invokeAndEncodeResponse(GWTService.java:550) 
     at org.jboss.seam.remoting.gwt.GWTService.processCall(GWTService.java:206) 
     at org.jboss.seam.remoting.gwt.GWTService$1.process(GWTService.java:120) 
     at org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:53) 
     at org.jboss.seam.remoting.gwt.GWTService.getResource(GWTService.java:105) 
     at org.jboss.seam.servlet.SeamResourceServlet.service(SeamResourceServlet.java:80) 
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) 
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) 
     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.web.LoggingFilter.doFilter(LoggingFilter.java:60) 
     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.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40) 
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) 
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) 
     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:619)

Nous utilisons JBoss AS 5.1.0.GA, Seam 2.2.0.GA et GWT 2.0.3. Le JBoss reçoit la requête d'Apache 2 via mod_jk. Le numéro de ligne fourni (Request.java:2517) indique que la méthode de la demande est null bien que les journaux de, firebug (client), Apache et mod_jk indiquent que la méthode est POST.

Actuellement, nous n'avons aucune idée de ce qui pourrait être la cause première de la NPE ni comment nous pourrions faire une solution de contournement. Nous spéculons si le problème a quelque chose à voir avec:

  • Collecte des ordures ménagères (JBoss est démarré avec -Dsun.rmi.dgc.client.gcInterval = 3600000 -Dsun.rmi.dgc.server.gcInterval = 3600000)
  • recyclage de la demande dans le filtre de recyclage de la chaîne Tomcat
  • dans Tomcat
  • mod_jk équilibre

Que pouvons-nous faire pour trouver la cause de ce problème? Y a-t-il une solution possible à ce problème?

Toute aide ou suggestion est vivement appréciée.

Merci!

-

Nous avons eu la chance et ont pu déboguer la trace de la pile pendant NPE. Nous avons découvert que les objets de demande dans MockExternalContext ne correspondent pas toujours aux objets de requête que le SeamResourceServlet reçoit. Parfois, l'objet de requête dans MockExternalContext est nouveau et contient une nouvelle instance de org.apache.coyote.Request avec tous les champs définis sur null. Si la demande peut être traitée, les objets de requête reçus par SeamResourceServlet sont identiques à ceux du MockExternalContext.

Est-ce que n'importe quel expert Seam peut nous aider et nous dire quand et où dans la pile ci-dessus trace le MockExternalContext qui est utilisé par org.jboss.seam.faces.Parameters est créé? Dans quelles circonstances Seam initialise le MockExternalContext avec un nouvel objet de requête plutôt qu'avec celui fourni par SeamResourceServlet? J'ai publié ce problème dans Seam forum.

-

Mise à jour

Dans le même temps, nous avons trouvé la raison pour laquelle les NPE:

Puisque nous utilisons GWT sur le côté client, toutes les communications client-serveur est fait via GWT-RPC de manière asynchrone. Très rarement, un appel de déconnexion dépasse un autre RPC en cours de traitement. L'appel de déconnexion invalide la session, de sorte que l'autre RPC ne peut pas se terminer normalement ce qui conduit à une exception pendant ServletLifecycle.endRequest (request); à l'intérieur du ContextualHttpServletRequest.Cette exception est gérée par ExceptionFilter de Seam. Malheureusement, le ExceptionFilter peut pas terminer normalement à cause de la session invalidée conduisant à l'erreur suivante:

 
ERROR [Seam Resource Servlet].error: Servlet.service() for servlet Seam Resource Servlet threw exception 
java.lang.IllegalStateException: Cannot create a session after the response has been committed 
     at org.apache.catalina.connector.Request.doGetSession(Request.java:2338) 
     at org.apache.catalina.connector.Request.getSession(Request.java:2094) 
     at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833) 
     at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216) 
     at org.jboss.seam.mock.MockExternalContext.getSessionMap(MockExternalContext.java:357) 
     at org.jboss.seam.contexts.FacesLifecycle.beginExceptionRecovery(FacesLifecycle.java:86) 
     at org.jboss.seam.web.ExceptionFilter.endWebRequestAfterException(ExceptionFilter.java:96) 
     at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:70) 
     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.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40) 
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) 
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) 
     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:619)

Le MockExternalContext qui est créé dans ExceptionFilter, séjours « en quelque sorte » dans le contexte d'application et qu'il est « parfois » utilisés pour traiter les demandes. Il survit même aux redéploiements de nos applications, de sorte que nous devons redémarrer JBoss pour se débarrasser des NPE.

Source

2010-06-22 kraftan

+0

Cela ressemble étrangement à un bug de sécurité de thread. JBossAS 5 utilise une version fourchue de Tomcat, donc je suggère de déposer un bug avec JBoss plutôt qu'avec Apache. – skaffman

+1

Merci pour cette suggestion, skaffman. Nous avions cela à l'esprit, aussi (demande de recyclage à Tomcat). Le fait que redémarrer JBoss tout en ayant un grand nombre de ces NPE a aidé instantanément, donne un autre indice dans cette direction. Je vais déposer un rapport de bug. – kraftan

+0

Modifier la question avec quelques informations supplémentaires que nous avons trouvées lors du débogage du NPE. – kraftan

Répondre

1

Merci TRÈS TRÈS pour cet article. Ce bug est notre cauchemar pour quelques semaines. Notre config est: GWT 2.0.4, Seam 2.2.1 CR2, JBoss AS 5.1.0. Nous avons corrigé le mécanisme de déconnexion dans notre application, mais il revient toujours (très rarement, cependant). Maintenant, il semble que cela se produit lorsqu'une transaction dure trop longtemps dans le niveau EJB. Maintenant nous sommes prêts à nous débarrasser de Seam, cela cause plus de problèmes que nous ne pouvons en supporter.

MISE À JOUR: Ce bogue étrange a disparu complètement lorsque la portée du composant « ServiceImpl » a été changé (juste enlevé) de « session » par défaut. L'annotation @BypassInterceptors a également été ajoutée. En attendant, j'ai préparé le remplacement du pont Seam-GWT pour notre application. C'est Guice + gwt-dispatch. Solution très rapide et fiable.

Source

2010-12-09 12:02:02 beastieboy

Questions connexes

 Questions connexes