[
https://issues.apache.org/jira/browse/LOG4J2-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1447:
--------------------------------
Description:
With each logging call, context map data is copied from the {{ThreadContext}}
map into the {{LogEvent}}.
The LogEvent interface exposes this data via the {{getContextMap() :
Map<String, String>}} method, and this is implementated by storing the data in
a Map<String, String>. The JDK Map is not an easy data structure to make
garbage-free. It would also be nice to have the ability in LogEvent to carry
data of any type.
One idea is to introduce a small interface that is general enough to be
map-like but can be implemented in a garbage-free manner.
LogEvent implementations would have an instance of this interface instead of
the current {{java.util.Map<String, String> contextMap}} attribute.
The interface could look something like this:
{code}
interface ContextData<String, V> {
/** Called to implement {@link LogEvent#getContextMap()}. */
Map<String, String> asMap();
/** Put key-value pair into the table.
Remove key if value is null. */
void put(String key, V value);
/** Returns the value for the specified key. */
V getValue(String key);
/** Number of key-value pairs. */
int size();
/** Removes all key-value pairs. */
void clear();
// Instead of Iterators, client code provides the consumer.
/**
* Performs the given action for each key-value pair in this data structure
* until all entries have been processed or the action throws an exception.
*/
void forEach(BiConsumer<String, ? super V> action);
}
/**
* An operation that accepts two input arguments and returns no result.
*/
interface BiConsumer<T,U> {
/** Performs the operation given the specified arguments. */
void accept(T t, U u);
}
{code}
The LogEvent interface would have an additional method {{getContextData() :
ContextData<K, V>}} that gives downstream components direct access to the new
data structure.
Existing downstream components would still be able to call
{{logEvent.getContextMap()}} to get a {{Map<String, String>}} view of the
context map data and this would work as expected.
was:
With each logging call, context map data is copied from the {{ThreadContext}}
map into the {{LogEvent}}.
The LogEvent interface exposes this data via the {{getContextMap() :
Map<String, String>}} method, and this is implementated by storing the data in
a Map<String, String>. The JDK Map is not an easy data structure to make
garbage-free. It would also be nice to have the ability in LogEvent to carry
data of any type.
One idea is to introduce a small interface that is general enough to be
map-like but can be implemented in a garbage-free manner.
LogEvent implementations would have an instance of this interface instead of
the current {{java.util.Map<String, String> contextMap}} attribute.
The interface could look something like this:
{code}
interface ContextData<K, V> {
/** Called to implement {@link LogEvent#getContextMap()}. */
Map<String, String> asMap();
/** Put key-value pair into the table.
Remove key if value is null. */
void put(K key, V value);
/** Returns the value for the specified key. */
V getValue(K key);
/** Number of key-value pairs. */
int size();
/** Removes all key-value pairs. */
void clear();
// Instead of Iterators, use an index-based approach.
/** Returns the index of the specified key. */
int indexOfKey(K key);
/** Returns the i-th key. */
K getKeyAt(int i);
/** Returns the value for the i-th key. */
V getValueAt(int i);
}
{code}
The LogEvent interface would have an additional method {{getContextData() :
ContextData<K, V>}} that gives downstream components direct access to the new
data structure.
Existing downstream components would still be able to call
{{logEvent.getContextMap()}} to get a {{Map<String, String>}} view of the
context map data and this would work as expected (although it may not be
garbage-free).
> Garbage-free data structure for LogEvent's context map data
> -----------------------------------------------------------
>
> Key: LOG4J2-1447
> URL: https://issues.apache.org/jira/browse/LOG4J2-1447
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.6.1
> Reporter: Remko Popma
> Assignee: Remko Popma
> Fix For: 2.7
>
>
> With each logging call, context map data is copied from the {{ThreadContext}}
> map into the {{LogEvent}}.
> The LogEvent interface exposes this data via the {{getContextMap() :
> Map<String, String>}} method, and this is implementated by storing the data
> in a Map<String, String>. The JDK Map is not an easy data structure to make
> garbage-free. It would also be nice to have the ability in LogEvent to carry
> data of any type.
> One idea is to introduce a small interface that is general enough to be
> map-like but can be implemented in a garbage-free manner.
> LogEvent implementations would have an instance of this interface instead of
> the current {{java.util.Map<String, String> contextMap}} attribute.
> The interface could look something like this:
> {code}
> interface ContextData<String, V> {
> /** Called to implement {@link LogEvent#getContextMap()}. */
> Map<String, String> asMap();
> /** Put key-value pair into the table.
> Remove key if value is null. */
> void put(String key, V value);
> /** Returns the value for the specified key. */
> V getValue(String key);
> /** Number of key-value pairs. */
> int size();
> /** Removes all key-value pairs. */
> void clear();
> // Instead of Iterators, client code provides the consumer.
> /**
> * Performs the given action for each key-value pair in this data
> structure
> * until all entries have been processed or the action throws an
> exception.
> */
> void forEach(BiConsumer<String, ? super V> action);
> }
> /**
> * An operation that accepts two input arguments and returns no result.
> */
> interface BiConsumer<T,U> {
> /** Performs the operation given the specified arguments. */
> void accept(T t, U u);
> }
> {code}
> The LogEvent interface would have an additional method {{getContextData() :
> ContextData<K, V>}} that gives downstream components direct access to the new
> data structure.
> Existing downstream components would still be able to call
> {{logEvent.getContextMap()}} to get a {{Map<String, String>}} view of the
> context map data and this would work as expected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
