ConcurrentModificationException during Tomcat startup (Filter startup in Tomcat)
Closed this issue · 4 comments
GoogleCodeExporter commented
We use javamelody version 1.4.7.
From time to time we are encountering the following bug during tomcat 7 startup
(filter startup of melody). Any ideas why this is happening and how this can be
avoided? Should the method be synchronized or the map be changed to
ConcurrentHashMap?
SEVERE: Exception starting filter monitoring
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
at java.util.HashMap$KeyIterator.next(Unknown Source)
at java.util.Collections$2.nextElement(Unknown Source)
at java.util.Collections.list(Unknown Source)
at net.bull.javamelody.LoggingHandler.register(LoggingHandler.java:79)
at net.bull.javamelody.FilterContext.initLogs(FilterContext.java:273)
at net.bull.javamelody.FilterContext.<init>(FilterContext.java:69)
at net.bull.javamelody.MonitoringFilter.init(MonitoringFilter.java:111)
at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:273)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:254)
at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:372)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:98)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4584)
at org.apache.catalina.core.StandardContext$2.call(StandardContext.java:5262)
at org.apache.catalina.core.StandardContext$2.call(StandardContext.java:5257)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Original issue reported on code.google.com by fg1232...@gmail.com
on 23 Jan 2014 at 9:54
GoogleCodeExporter commented
> ConcurrentModificationException ... Should the method be synchronized or the
map be changed to ConcurrentHashMap?
Yes.
Except that the map is in the JDK/JRE ("namedLoggers" in
java.util.logging.LogManager). And I can't add synchronized or
ConcurrentHashMap in the JDK myself, nor prevent other threads to use the JDK.
(In fact, there is already "synchronized", a clone is only missing in that
"synchronized".)
There is already an issue for that in the Java bugdatabase, which explains and
gives the fix for JDK. It was created by a guy named Kohsuke.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6935026
Unfortunately, the bug was said as "Cannot reproduce" without a fix.
Original comment by evernat@free.fr
on 24 Jan 2014 at 10:56
GoogleCodeExporter commented
I have added a work around to the JDK bug.
It's in the trunk (revision 3643) and ready for the next release (1.50).
And I have made a new build from the trunk, including the work around.
The new build is attached in this issue.
Original comment by evernat@free.fr
on 24 Jan 2014 at 11:17
- Changed state: Fixed
Attachments:
GoogleCodeExporter commented
To be more correct. It is a JDK bug which also exists in
org.apache.juli.ClassLoaderLogManager of Tomcat.
Original comment by evernat@free.fr
on 28 Jan 2014 at 3:39
GoogleCodeExporter commented
There is an issue for this in Tomcat bugtracker:
https://issues.apache.org/bugzilla/show_bug.cgi?id=56082
As said by Mark Thomas: "This has been fixed in 8.0.x for 8.0.2 onwards and in
7.0.x for 7.0.51 onwards. It has also been proposed for 6.0.x.".
Note that the workaround is kept in javamelody for older Tomcat versions.
Original comment by evernat@free.fr
on 31 Jan 2014 at 10:06