Is it wise to enable by default given that "multi-threaded applications that use synchronous logging may see worse performance"?
On Mon, Apr 18, 2016 at 2:22 PM, Remko Popma <remko.po...@gmail.com> wrote: > Enabled, except for web apps; for those log4j will be low garbage. > > See the first paragraph of the Configuration section in the manual page. > > Please let me know if this is not clear. (The fact that you asked means > this probably needs improvement...) > > Sent from my iPhone > > On 2016/04/18, at 20:18, Mikael Ståldal <mikael.stal...@magine.com> wrote: > > Will garbage-free logging be enabled or disabled by default? > > On Mon, Apr 18, 2016 at 2:58 AM, Remko Popma (JIRA) <j...@apache.org> > wrote: > >> >> [ >> https://issues.apache.org/jira/browse/LOG4J2-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245018#comment-15245018 >> ] >> >> Remko Popma commented on LOG4J2-1297: >> ------------------------------------- >> >> TODO allocate many temporary objects -> allocate temporary objects >> >> TODO multi-threaded applications that use synchronous logging may see >> worse performance: the lock that was previously only around the IO >> operation is widened to include the text formatting and conversion to >> bytes. -> _synchronous_ logging performance may be worse for multi-threaded >> applications in this mode due to synchronization on the shared buffer. If >> your application is multi-threaded and logging performance is important, >> consider using Async Loggers. >> >> TODO Caution: Only dates in the predefined formats are garbage-free -> >> Caution: Only the predefined date formats are garbage-free >> >> TODO "(Note that Log4j may call toString() on message and parameter >> objects when garbage-free logging is disabled because system property >> log4j2.enable.threadlocals is set to "false".)" -> Log4j may call >> toString() on message and parameter objects when garbage-free logging is >> disabled (when system property log4j2.enable.threadlocals is set to >> "false".) >> >> TODO "made an effort to make logging code garbage-free" -> "made an >> effort to make logging garbage-free" >> >> >> > Document "gc-free" configuration and performance >> > ------------------------------------------------ >> > >> > Key: LOG4J2-1297 >> > URL: https://issues.apache.org/jira/browse/LOG4J2-1297 >> > Project: Log4j 2 >> > Issue Type: New Feature >> > Components: Documentation >> > Affects Versions: 2.5 >> > Reporter: Remko Popma >> > Assignee: Remko Popma >> > Fix For: 2.6 >> > >> > Attachments: log4j-2.5-FlightRecording.png, >> log4j-2.6-FlightRecording.png >> > >> > >> > Update the site with a description of which configurations are GC-free >> (i.e., that don't create temporary objects in steady running state). >> > Currently that means >> > * Loggers are all asynchronous (Log4jContextSelector is set to >> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector). >> > * The configuration does not contain a <Properties> section. >> > * The "steady-state" appenders are either RandomAccessFile or >> RollingRandomAccessFile Appenders (logging to any other appender will cause >> temporary objects to be created - including ConsoleAppender). >> > * The Layout is a PatternLayout that uses one of the pre-defined date >> formats, does not have any regular expression replacements, and does not >> have lookups (TODO: may need to restrict this further). >> > * The thread name is cached (this is the [default| >> https://issues.apache.org/jira/browse/LOG4J2-467]). Running with >> -DAsyncLogger.ThreadNameStrategy=UNCACHED will create garbage. >> > * In user code, when logging a parameterized message, the number of >> parameters is no more than ... (TBD pending discussion in LOG4J2-1278). >> > * In user code, when logging a parameterized message, parameters of >> primitive type are boxed in a reused StringBuilder (Log4j provides a >> utility to make this relatively painless). >> > Even with the above restrictions, Log4j may occasionally create garbage: >> > * Initially StringBuilders are presized to 128 characters. They may >> grow for larger messages (contributing to garbage in Old Gen). If the >> StringBuilder grows beyond 512 characters it is trimmed back to 512 >> characters to prevent memory leaks from excessively long messages. (TODO: >> the resizing algorithm is {{size = value.length * 2 + 2}}, so a better >> cutoff value is 518.) >> > * Messages containing {{"$\{"}} will be converted to a String and >> StrSubstitutor will be used to replace occurences of variables with their >> matching values. Multiple temporary objects are created during this process. >> > Furthermore, we need to explain that some of this functionality depends >> on ThreadLocals and so is disabled by default in web applications to >> prevent memory leaks. The page should also explain how to manually switch >> off the use of ThreadLocals. >> > Finally, the page should show a performance test comparison similar to >> the [performance section| >> http://logging.apache.org/log4j/2.x/manual/async.html#Performance] on >> the Async Loggers page. I'm thinking a comparison between Logback, Log4j-1, >> Log4j-2.0, Log4j-2.6 "classic" and Log4j-2.6 "gc-free" would be ideal. >> >> >> >> -- >> 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 >> >> > > > -- > [image: MagineTV] > > *Mikael Ståldal* > Senior software developer > > *Magine TV* > mikael.stal...@magine.com > Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com > > Privileged and/or Confidential Information may be contained in this > message. If you are not the addressee indicated in this message > (or responsible for delivery of the message to such a person), you may not > copy or deliver this message to anyone. In such case, > you should destroy this message and kindly notify the sender by reply > email. > > -- [image: MagineTV] *Mikael Ståldal* Senior software developer *Magine TV* mikael.stal...@magine.com Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email.
