[ https://issues.apache.org/jira/browse/LOG4J2-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002951#comment-16002951 ]
ASF GitHub Bot commented on LOG4J2-1874: ---------------------------------------- Github user remkop commented on the issue: https://github.com/apache/logging-log4j2/pull/71 Do all tests pass when you run `mvn clean install` on your machine? (may take ~20 minutes) On Wednesday, May 10, 2017 12:34 AM, Roman Leventov <notificati...@github.com> wrote: @remkop this test used to depend on specific line numbers in this test. Made it more generic.— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread. > 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)