After looking at the code I am sure there is something wrong with the logic. While you can set property log4j2.enable.direct.encoders to true or false it uses the same Encoder in either case.
As for why it is not a class member variable, that would be because it wouldn’t be thread-safe if it was. The encoder is a member of PatternLayout and multiple threads can be using the same PatternLayout at the same time. That said, even then I’m not sure why it has to be synchronized. Will the ByteBuffer be manipulated from other threads while the Layout is being rendered? That would require asynchronous pattern converters. Ralph > On Mar 15, 2020, at 3:37 AM, Volkan Yazıcı <[email protected]> wrote: > > Hello, > > I want to take advantage of StringBuilder plumbing in the core module. > There are two Encoder<StringBuilder> implementations: > StringBuilderEncoder and LockingStringBuilderEncoder. Given > JsonTemplateLayout has its own customizable recycling strategy, I > can't use StringBuilderEncoder due to its TLAs. > LockingStringBuilderEncoder, even though I cannot find any usage of > this class, contains the following interesting bit: > > // This synchronized is needed to be able to call destination.getByteBuffer() > synchronized (destination) { > TextEncoderHelper.encodeText(charsetEncoder, cachedCharBuffer, > destination.getByteBuffer(), source, > destination); > } > > Why doesn't there exist a ByteBuffer class field but rather it relies > on destination.getByteBuffer()? This would have eliminated the need > for the synchronized block. For instance, StringBuilderEncoder has its > own thread-local ByteBuffer and avoids the synchronized. > > Kinds regards. >
