Description
The current ThreadContext map and stack implementations allocate temporary objects. This ticket is to investigate and track the work for alternative implementations that are garbage-free.
Both DefaultThreadContextMap and DefaultThreadContextStack are copy-on-write data structures: each modification replaces the ThreadLocal object with a modified copy. The advantage of this approach is that there is no need to make a copy for each LogEvent.
Also, DefaultThreadContextMap uses a JDK map, the JDK collections tend to allocate a lot of temporary objects.
Attachments
Attachments
Issue Links
- is depended upon by
-
LOG4J2-1401 Support changing the log level for all messages related to some domain object
-
- Closed
-
- is related to
-
LOG4J2-1648 Provide ability for users to put non-String values in the ThreadContext
-
- Open
-
-
LOG4J2-1607 Improve performance of SortedArrayStringMap data structure
-
- Closed
-
- relates to
-
LOG4J2-1516 Add ThreadContextMap.putAll(Map<String, String>)
-
- Resolved
-
-
LOG4J2-1517 Add ThreadContext.setContext(Map<String, String>)
-
- Resolved
-
-
LOG4J2-1519 Add ThreadContext.putAll(Map<String, String>)
-
- Closed
-
-
LOG4J2-1010 Injectable context properties
-
- Closed
-
-
LOG4J2-1447 Garbage-free data structure for LogEvent's context map data
-
- Closed
-
-
LOG4J2-1660 ThreadContext to expose ReadOnlyThreadContextMap internal data structure
-
- Closed
-
- supercedes
-
LOG4J2-1282 Make RingBufferLogEvent::mergePropertiesIntoContextMap allocation-free if possible
-
- Closed
-