search

5608057 / javamelody

Automatically exported from code.google.com/p/javamelody
0 stars 0 forks source link

ConcurrentModificationException during Tomcat startup (Filter startup in Tomcat) #370

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
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 8 years ago 
> 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 8 years ago 
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

Attachments:

GoogleCodeExporter commented 8 years ago 
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 8 years ago 
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