On Sun, Mar 15, 2020 at 6:03 PM Ralph Goers <[email protected]> wrote:
> 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.
I am a little bit puzzled here. Which particular "logic" are you
referring to exactly? The following in AbstractStringLayout?
protected AbstractStringLayout(
final Charset aCharset,
final byte[] header,
final byte[] footer) {
// ...
textEncoder = Constants.ENABLE_DIRECT_ENCODERS
? new StringBuilderEncoder(charset)
: null;
}
protected Encoder<StringBuilder> getStringBuilderEncoder() {
if (textEncoder == null) {
textEncoder = new StringBuilderEncoder(getCharset());
}
return textEncoder;
}
If so, what should have been the correct logic?
> 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 was exactly the question in my mind. I had the impression that
TextEncoderHelper.encodeText() is supposed to take the necessary
synchronization measures.
BTW, LockingStringBuilderEncoder is not used anywhere, right? Am I
missing something?
Speaking of ENABLE_DIRECT_ENCODERS flag, what does it exactly mean
when it's set to false? That is, if my layout can perfectly drain its
output into a ByteBufferDestination without any TLAs or such, what is
the point of disabling it because user has just requested that?
