ConcurrentModificationException in Pages.java + strange wildcards configuration processing? ------------------------------------------------------------------------------------------- Key: JBSEAM-2358 URL: http://jira.jboss.com/jira/browse/JBSEAM-2358 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 2.0.0.GA Environment: Seam-CVS 2007-12-07, Tomcat 6.0.13 Reporter: Przemyslaw Jaskierski Priority: Blocker Fix For: 2.0.1.GA During heavy load testing session I've got this after few seconds and few successful requests: * 2007-12-07 20:59:27,148 ERROR SeamPhaseListener.afterPhase():189 uncaught exception java.util.ConcurrentModificationException at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1100) at java.util.TreeMap$KeyIterator.next(TreeMap.java:1152) at org.jboss.seam.navigation.Pages.createPageStack(Pages.java:233) at org.jboss.seam.navigation.Pages.getPageStack(Pages.java:220) at org.jboss.seam.navigation.Pages.storeRequestStringValuesInPageContext(Pages.java:706) at org.jboss.seam.navigation.Pages.postRestore(Pages.java:364) at org.jboss.seam.jsf.SeamPhaseListener.postRestorePage(SeamPhaseListener.java:535) at org.jboss.seam.jsf.SeamPhaseListener.afterRestoreView(SeamPhaseListener.java:381) at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:218) at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:184) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:280) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244) 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.MultipartFilter.doFilter(MultipartFilter.java:85) 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:141) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281) at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68) 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.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:445) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292) at org.tuckey.web.filters.urlrewrite.NormalRewrittenUrl.doRewrite(NormalRewrittenUrl.java:183) at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:125) at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:107) at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:78) at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:383) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at net.sf.ehcache.constructs.web.filter.GzipFilter.doFilter(GzipFilter.java:75) at net.sf.ehcache.constructs.web.filter.Filter.doFilter(Filter.java:92) 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:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) It originates from this foreach: 233: for (String wildcard: wildcardViewIds) Thread safety is only one thing here. If this is the case of concurrent modification of "wildcardViewIds" the question is why it is altered long after application starts? After briefly skimming through this code this structure holds configuration of wildcard page patterns. Why is it changing in time when no altering of pages.xml is performed? Is it optimal? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira