[
https://issues.apache.org/jira/browse/LOG4J2-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002782#comment-16002782
]
ASF GitHub Bot commented on LOG4J2-1874:
----------------------------------------
Github user jvz commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/71#discussion_r115505200
--- Diff:
log4j-core/src/main/java/org/apache/logging/log4j/core/layout/StringBuilderEncoder.java
---
@@ -32,9 +32,14 @@
public class StringBuilderEncoder implements Encoder<StringBuilder> {
private static final int DEFAULT_BYTE_BUFFER_SIZE = 8 * 1024;
- private final ThreadLocal<CharBuffer> charBufferThreadLocal = new
ThreadLocal<>();
- private final ThreadLocal<ByteBuffer> byteBufferThreadLocal = new
ThreadLocal<>();
- private final ThreadLocal<CharsetEncoder> charsetEncoderThreadLocal =
new ThreadLocal<>();
+ /**
+ * This ThreadLocal uses raw and inconvenient Object[] to store three
heterogeneous objects (CharEncoder, CharBuffer
--- End diff --
So why can't you use three separate thread locals?
> 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)
