[
https://issues.apache.org/jira/browse/LOG4J2-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1629:
--------------------------------
Fix Version/s: (was: 2.7)
Description:
For some applications like financial trading systems, highly interactive games
or numerical computation-heavy scientific applications, a large portion of data
is stored in primitives. Applications like this sometimes need to set such
values in the logging context (e.g., order ID, algo strategy instance ID, etc)
and would prefer to avoid the overhead of boxing/unboxing these primitives.
Building on top of the work done for LOG4J2-1447 and LOG4J2-1349, this ticket
proposes to add interfaces extending ThreadContextMap2, StringMap and
ReadOnlyStringMap to add support for primitive values:
{code}
public interface ThreadContextMap3 extends ThreadContextMap2 {
long getLong(String key);
void putLong(String key, long value);
boolean containsLong(String key);
/** The value {@link #getLong()} should return if the map
* doesn't have a long value for the specified key.
*/
long getDefaultLong();
void setDefaultLong(long defaultValue);
}
{code}
{code}
public interface ReadOnlyHybridStringMap extends ReadOnlyStringMap {
long getLong(String key);
boolean containsLong(String key);
long getDefaultLong();
void setDefaultLong(long defaultValue);
void forEach(HybridBiConsumer action);
void forEach(HybridTriConsumer action);
}
{code}
{code}
public interface HybridStringMap extends StringMap {
void putLong(String key, long value);
}
{code}
The semantics remain the same as a normal map: there is at most one value for a
key. Putting a value with the same key replaces the old value with that key,
regardless of whether the old value was an Object or a primitive.
An API supporting only primitive long values is sufficient because all
primitives can be represented as a 64 bit long. For example, a double can be
converted to a long and back with the {{Double.doubleToLongBits(double)}}
method and its reverse. Applications can decorate the Log4j interfaces with
custom facades that provide separate methods for different primitive types if
required.
For iteration, new interfaces HybridBiConsumer and HybridTriConsumer are
introduced. These interfaces are similar to the previous Consumer interfaces
except that their {{accept}} method will take an additional {{long}} parameter:
{code}
public interface HybridBiConsumer<K, V> {
/**
* Performs the operation given the specified arguments.
* @param key the first input argument
* @param objectValue the second input argument as an Object of type
* {@code V}, or {@code null} if the value is a primitive long
* @param longValue the second input argument as a primitive long, or
* a default value if the underlying value is not a primitive
value
*/
void accept(K key, V objectValue, long longValue);
}
{code}
was:
For some applications like financial trading systems, highly interactive games
or numerical computation-heavy scientific applications, a large portion of data
is stored in primitives. Applications like this sometimes need to set such
values in the logging context (e.g., order ID, algo strategy instance ID, etc)
and would prefer to avoid the overhead of boxing/unboxing these primitives.
Building on top of the work done for LOG4J2-1447 and LOG4J2-1349, this ticket
proposes to add the following methods to the ThreadContextMap2, StringMap and
ReadOnlyStringMap interfaces:
{code}
// ReadOnlyStringMap and ThreadContextMap2 additional methods
long getLong(String key);
boolean containsLong(String key);
/** The value {@link #getLong()} should return if the map
* doesn't have a long value for the specified key.
*/
long getDefaultLong();
void setDefaultLong(long defaultValue);
// StringMap additional method (also in ThreadContextMap2)
void putLong(String key, long value);
{code}
The semantics remain the same as a normal map: there is at most one value for a
key. Putting a value with the same key replaces the old value with that key,
regardless of whether the old value was an Object or a primitive.
An API supporting only primitive long values is sufficient because all
primitives can be represented as a 64 bit long. For example, a double can be
converted to a long and back with the {{Double.doubleToLongBits(double)}}
method and its reverse. Applications can decorate the Log4j interfaces with
custom facades that provide separate methods for different primitive types if
required.
For iteration, the BiConsumer and TriConsumer's {{accept}} method will take an
additional {{long}} parameter:
{code}
public interface BiConsumer<K, V> {
/**
* Performs the operation given the specified arguments.
* @param key the first input argument
* @param objectValue the second input argument as an Object of type
* {@code V}, or {@code null} if the value is a primitive long
* @param longValue the second input argument as a primitive long, or
* a default value if the underlying value is not a primitive
value
*/
void accept(K key, V objectValue, long longValue);
}
{code}
It would be good if we can include these methods in the 2.7 release.
ThreadContextMap2 and the StringMap interfaces are new so at this stage we
don't need to be concerned with backwards compatibility.
My original idea was to add primitive support directly to the
ThreadContextMap2, StringMap and ReadOnlyStringMap interfaces, but after trying
this out I was not too happy with the result.
Extending these interfaces seems like a better idea now.
Now looking at minimum changes that allow us to let the above extensions be
introduced later (after 2.7).
> Support for primitive values in StringMap
> -----------------------------------------
>
> Key: LOG4J2-1629
> URL: https://issues.apache.org/jira/browse/LOG4J2-1629
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.7
> Reporter: Remko Popma
> Assignee: Remko Popma
>
> For some applications like financial trading systems, highly interactive
> games or numerical computation-heavy scientific applications, a large portion
> of data is stored in primitives. Applications like this sometimes need to set
> such values in the logging context (e.g., order ID, algo strategy instance
> ID, etc) and would prefer to avoid the overhead of boxing/unboxing these
> primitives.
> Building on top of the work done for LOG4J2-1447 and LOG4J2-1349, this ticket
> proposes to add interfaces extending ThreadContextMap2, StringMap and
> ReadOnlyStringMap to add support for primitive values:
> {code}
> public interface ThreadContextMap3 extends ThreadContextMap2 {
> long getLong(String key);
> void putLong(String key, long value);
> boolean containsLong(String key);
> /** The value {@link #getLong()} should return if the map
> * doesn't have a long value for the specified key.
> */
> long getDefaultLong();
> void setDefaultLong(long defaultValue);
> }
> {code}
> {code}
> public interface ReadOnlyHybridStringMap extends ReadOnlyStringMap {
> long getLong(String key);
> boolean containsLong(String key);
> long getDefaultLong();
> void setDefaultLong(long defaultValue);
> void forEach(HybridBiConsumer action);
> void forEach(HybridTriConsumer action);
> }
> {code}
> {code}
> public interface HybridStringMap extends StringMap {
> void putLong(String key, long value);
> }
> {code}
> The semantics remain the same as a normal map: there is at most one value for
> a key. Putting a value with the same key replaces the old value with that
> key, regardless of whether the old value was an Object or a primitive.
> An API supporting only primitive long values is sufficient because all
> primitives can be represented as a 64 bit long. For example, a double can be
> converted to a long and back with the {{Double.doubleToLongBits(double)}}
> method and its reverse. Applications can decorate the Log4j interfaces with
> custom facades that provide separate methods for different primitive types if
> required.
> For iteration, new interfaces HybridBiConsumer and HybridTriConsumer are
> introduced. These interfaces are similar to the previous Consumer interfaces
> except that their {{accept}} method will take an additional {{long}}
> parameter:
> {code}
> public interface HybridBiConsumer<K, V> {
> /**
> * Performs the operation given the specified arguments.
> * @param key the first input argument
> * @param objectValue the second input argument as an Object of type
> * {@code V}, or {@code null} if the value is a primitive
> long
> * @param longValue the second input argument as a primitive long, or
> * a default value if the underlying value is not a
> primitive value
> */
> void accept(K key, V objectValue, long longValue);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
