[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2358) ConcurrentModificationException in Pages.java + strange wildcards configuration processing?

Przemyslaw Jaskierski (JIRA) jira-events at lists.jboss.org
Fri Dec 7 15:19:01 EST 2007


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

        



More information about the seam-issues mailing list