[
https://issues.apache.org/jira/browse/LOG4J2-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1270:
--------------------------------
Description:
In certain fields like finance, predictable latency is very important, and
applications in this space tend to carefully manage their object allocation to
avoid unpredictable GC pauses. As of 2.5, Log4j is not suitable to be included
in such applications since it allocates new objects while running in its steady
state.
This ticket is to investigate the feasibility of modifying some key components
in Log4j to provide a configuration that does not allocate new objects in its
steady state. (Initialization or shutdown don't need to be allocation-free.)
To clarify, I am not proposing to make all of Log4j allocation-free. My goal is
to create an allocation-free execution path in Log4j with some reasonable
subset of the Log4j functionality. For example, make logging garbage-free if
all of these conditions are met:
* all loggers are AsyncLoggers
* you only use the RandomAccessFileAppender
* you only use a PatternLayout without any regular expression replacements,
without lookups and with one of the pre-defined date formats.
Further restrictions may be necessary.
----
Update:
The scope has been expanded to
* include both synchronous and asynchronous loggers
* include the most common appenders: console, file and random access file
appender (both with rolling variants)
----
The tickets below list separate pieces of work necessary to accomplish this.
was:
In certain fields like finance, predictable latency is very important, and
applications in this space tend to carefully manage their object allocation to
avoid unpredictable GC pauses. As of 2.5, Log4j is not suitable to be included
in such applications since it allocates new objects while running in its steady
state.
This ticket is to investigate the feasibility of modifying some key components
in Log4j to provide a configuration that does not allocate new objects in its
steady state. (Initialization or shutdown don't need to be allocation-free.)
To clarify, I am not proposing to make all of Log4j allocation-free. My goal is
to create an allocation-free execution path in Log4j with some reasonable
subset of the Log4j functionality. For example, make logging garbage-free if
all of these conditions are met:
* all loggers are AsyncLoggers
* you only use the RandomAccessFileAppender
* you only use a PatternLayout without any regular expression replacements,
without lookups and with one of the pre-defined date formats.
Further restrictions may be necessary.
----
Update April 21:
The scope has been expanded to
* both synchronous and asynchronous loggers
* console appender, file appender and random access file appender (both with
rolling variants)
----
The tickets below list separate pieces of work necessary to accomplish this.
> Garbage-free steady-state logging
> ---------------------------------
>
> Key: LOG4J2-1270
> URL: https://issues.apache.org/jira/browse/LOG4J2-1270
> Project: Log4j 2
> Issue Type: Epic
> Components: API, Appenders, Core, Layouts, Pattern Converters
> Affects Versions: 2.5
> Reporter: Remko Popma
> Labels: gc
>
> In certain fields like finance, predictable latency is very important, and
> applications in this space tend to carefully manage their object allocation
> to avoid unpredictable GC pauses. As of 2.5, Log4j is not suitable to be
> included in such applications since it allocates new objects while running in
> its steady state.
> This ticket is to investigate the feasibility of modifying some key
> components in Log4j to provide a configuration that does not allocate new
> objects in its steady state. (Initialization or shutdown don't need to be
> allocation-free.)
> To clarify, I am not proposing to make all of Log4j allocation-free. My goal
> is to create an allocation-free execution path in Log4j with some reasonable
> subset of the Log4j functionality. For example, make logging garbage-free if
> all of these conditions are met:
> * all loggers are AsyncLoggers
> * you only use the RandomAccessFileAppender
> * you only use a PatternLayout without any regular expression replacements,
> without lookups and with one of the pre-defined date formats.
> Further restrictions may be necessary.
> ----
> Update:
> The scope has been expanded to
> * include both synchronous and asynchronous loggers
> * include the most common appenders: console, file and random access file
> appender (both with rolling variants)
> ----
> The tickets below list separate pieces of work necessary to accomplish this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
