[
https://issues.apache.org/jira/browse/LOG4J2-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13784947#comment-13784947
]
Remko Popma commented on LOG4J2-416:
------------------------------------
I'm not sure if it is possible to do this in a generic way.
Essentially if you pass an Object to one of the logger methods, the logger will
turn that object into a String. We assume that the {{toString}} method will not
throw any exceptions. (Which raises another, different, issue: should we catch
exceptions thrown by {{toString}}, if if so, how should they be handled?)
Back to your request: the logger methods take an Object argument. Log4J would
have to do an instanceof on that Object and create a copy, distinguishing
between HashMap, and TreeMap (because their toString gives different results),
and all other known implementation of the java.util collections classes. But
this would not cover any alternative collection classes like [1]...
Personally I think creating a copy is the responsibility of the application,
not the logging library.
[1] http://java.dzone.com/articles/java-collections-%E2%80%93-are-there
> ConcurrentModificationException when logging maps that are being worked on
> --------------------------------------------------------------------------
>
> Key: LOG4J2-416
> URL: https://issues.apache.org/jira/browse/LOG4J2-416
> Project: Log4j 2
> Issue Type: Bug
> Components: API
> Affects Versions: 2.0-beta9
> Reporter: Dimitry Declercq
>
> We run a multi-thread application which logs Maps, after log.debug(map) we
> continue to add items to the map, resulting in a
> ConcurrentModificationException on the logging side.
> e.g
> thread1 adds 4 items to the map
> thread1 logs the map
> thread2 receives map and adds 2 extra items
> thread2 logs the map as well (not needed to trigger this issue)
> The logging of the map in thread 1 will sometimes fail with a
> ConcurrentModificationException.
> This is solved by logging a copy instead of the working variable, but I think
> it would be good if Log4J does this out of the box
> Stacktrace:
> Exception in thread "Thread-38" java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:894)
> at java.util.HashMap$EntryIterator.next(HashMap.java:934)
> at java.util.HashMap$EntryIterator.next(HashMap.java:932)
> at
> org.apache.logging.log4j.message.ParameterizedMessage.recursiveDeepToString(ParameterizedMessage.java:463)
> at
> org.apache.logging.log4j.message.ParameterizedMessage.deepToString(ParameterizedMessage.java:378)
> at
> org.apache.logging.log4j.message.ParameterizedMessage.parseArguments(ParameterizedMessage.java:164)
> at
> org.apache.logging.log4j.message.ParameterizedMessage.<init>(ParameterizedMessage.java:117)
> at
> org.apache.logging.log4j.message.ParameterizedMessage.<init>(ParameterizedMessage.java:126)
> at org.slf4j.impl.SLF4JLogger.debug(SLF4JLogger.java:145)
> at
> com.lynx.api.rest.service.PriceResource.getPrice(PriceResource.java:74)
> at
> com.lynx.api.rest.service.PriceResourceTest$1.run(PriceResourceTest.java:166)
> at java.lang.Thread.run(Thread.java:722)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
