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

Remko Popma commented on LOG4J2-1329:
-------------------------------------

Ok, I see now. To summarize:

* You need to iterate over the message text one character at a time anyway, so 
it would be convenient if the Message interface (or some extension interface) 
provided a way to do this. 
* One way to solve this would be by asking the Message to write its contents 
into a second temporary buffer with {{formatTo(StringBuilder)}}, and then 
process the data in that second buffer.
* However, it seems wasteful to copy this text in the case where the Message 
already has a fully prepared CharSequence (String or StringBuilder).

The question is then: how often is it the case that a Message already has a 
fully prepared CharSequence?

I think there will be two cases:
# Synchronous gc-free logging: this will likely _not_ have formatted text. 
ReusableParameterizedMessage for example does not create the formatted text 
until {{formatTo(StringBuilder)}} is called, so there will be no unnecessary 
copying in this case.
# Asynchronous gc-free logging: this _will_ have formatted text because of the 
need to format the message before the hand-off to the background thread.

Which is interesting because it means we would be optimizing the background 
thread of the async logging case. Do we still want to do this?

> API change: let Message.getFormattedMessage() return CharSequence instead of 
> String
> -----------------------------------------------------------------------------------
>
>                 Key: LOG4J2-1329
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1329
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 2.5
>            Reporter: Remko Popma
>
> I propose that we change {{Message.getFormattedMessage()}} to return a 
> {{CharSequence}} instead of a String.
> I believe this change would be backwards compatible (all Message 
> implementations that return a String will work as is), and it opens the way
> for zero-GC Message implementations to return a cached StringBuilder as 
> Mikael [suggested on the log4j-dev mailing 
> list|http://mail-archives.apache.org/mod_mbox/logging-log4j-dev/201603.mbox/%3CCAAFrFhSs4EqjOERwHObKAZP4wjGWeiCET1nyE1FVndYdePk2yw%40mail.gmail.com%3E].



--
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

Reply via email to