[
https://issues.apache.org/jira/browse/LOG4J2-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15970393#comment-15970393
]
ASF GitHub Bot commented on LOG4J2-1874:
----------------------------------------
Github user remkop commented on the issue:
https://github.com/apache/logging-log4j2/pull/71
@leventov Quick update: Started to look at the PR but did not get far yet.
I'm taking my time because this is a fairly sensitive area. When converting the
OutputStreamAppender and *FileAppenders to the ByteBufferDestination API for
the garbage-free epic it took me a few tries to get it right. A complicating
factor is that there may be users who subclassed any of these classes, and we
don't want to break their stuff. At first glance your proposal does not affect
that but I haven't spent enough time with it yet to be sure. (Did all the tests
pass for you? I have some environment trouble and haven't been able to try yet.)
> Add ByteBufferDestionation.write(ByteBuffer) and write(byte[], int, int)
> methods and call them from TextEncoderHelper whenever possible
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LOG4J2-1874
> URL: https://issues.apache.org/jira/browse/LOG4J2-1874
> Project: Log4j 2
> Issue Type: Improvement
> Reporter: Roman Leventov
> Assignee: Remko Popma
>
> Existing ByteBufferDestination API: getByteBuffer() and drain() is designed
> so that synchronization couldn't be avoided. This doesn't allow to implement
> LOG4J2-928.
> Github PR: https://github.com/apache/logging-log4j2/pull/71
> Added methods: write(ByteBuffer data) and write(byte[] data, int offset, int
> length) are designed so that they should care about synchronization
> themselves, internally, if needed. They should also synchronize with possible
> concurrent users of the synchronized getByteBuffer() + drain() API.
> Nevertheless, it allows for ByteBufferDestination implementations to
> implement write() methods without lock-free.
> TextEncoderHelper (hence StringBuilderEncoder, which delegates it's logic to
> TextEncoderHelper) is changed so that it calls ByteBufferDestination.write()
> whenever possible. There is an expectation that most of encoded events fit
> the thread-local buffers, and write() could be called instead of writing to
> destination.getByteBuffer() with synchronization.
> The PR also includes a sanity improvement: uses ByteBuffer.arrayOffset() at
> some places.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
