Details
-
Bug
-
Resolution: Fixed
-
Low
-
3.3
-
None
Description
I don't know how much performance impact this actually has, but I've seen the following a couple of times in thread dumps. (this one from 3.3.3)
java.lang.Thread.State: BLOCKED (on object monitor) at java.util.logging.Logger.getHandlers(Logger.java:1219) - locked <0x00000006e01678d8> (a org.apache.juli.ClassLoaderLogManager$RootLogger) at java.util.logging.Logger.log(Logger.java:477) at java.util.logging.Logger.doLog(Logger.java:503) at java.util.logging.Logger.log(Logger.java:526) at java.util.logging.Logger.fine(Logger.java:1077) at net.sf.ehcache.store.MemoryStore.get(MemoryStore.java:172)
This can be entirely avoided by adding the following line to the logging.properties file
net.sf.ehcache.level = WARNING
The problem is that we use SLF4JBridgeHandler for ALL unless otherwise specified, which by its own documentation says this:
Please note that translating a java.util.logging event into SLF4J incurs the cost of constructing LogRecord instance regardless of whether the SLF4J logger is disabled for the given level. Consequently, j.u.l. to SLF4J translation can seriously impact on the cost of disabled logging statements (60 fold increase) and a measurable impact on enabled log statements (20% overall increase). If application performance is a concern, then use of SLF4JBridgeHandler is appropriate only if few j.u.l. logging statements are in play.
If we turn down the ehcache logging as standard, and document how to turn it up (by simply changing the value in logging.properties), I think it would be worthwhile.