logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4J2-1447) Garbage-free data structure for LogEvent's context map data
Date Sat, 09 Jul 2016 07:50:10 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368987#comment-15368987
] 

Ralph Goers edited comment on LOG4J2-1447 at 7/9/16 7:49 AM:
-------------------------------------------------------------

The only issue I have is with the put and clear methods. If the data structure is immutable
the interface exposed to Filters, Appenders, etc shouldn't allow modification. Of course,
the actual implementation class can have a put method or whatever is needed to populate the
data structure.


was (Author: ralph.goers@dslextreme.com):
The only issue I have is with the put method. If the data structure is immutable the interface
exposed to Filters, Appenders, etc shouldn't allow modification. Of course, the actual implementation
class can have a put method or whatever is needed to populate the data structure.

> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message