The requirement for core is, and will always be, that it can work without any
additional libraries. In the places we use Thread Locals we would require that
the Object Pooling logic be part of Log4j, not in another jar.
Ralph
> On Jan 8, 2020, at 4:32 PM, Gary Gregory wrote:
>
> Can we plea
Are you still considering contributing this?
Ralph
> On Jan 8, 2020, at 2:42 PM, Volkan Yazıcı wrote:
>
> On Tue, Dec 24, 2019 at 10:48 PM Volkan Yazıcı
> wrote:
>> In its current form, LogstashLayout can (almost) very well render the
>> GELF layout[1]. There are only two shortcomings: 1) epo
Can we please not invent yet another pooling mechanism at Apache? ;-) OTOH
bringing in Apache Commons Pool might be too heavy handed.
For the two main server stacks I work on at my day job, it's not an issue
since I already use Commons Pool. Actually, now that I think of it: Commons
DBCP (which de
On Tue, Jan 7, 2020 at 12:36 AM Ralph Goers wrote:
> I am not against making a change but I would need to see performance results
> before it gets merged.
Unless my knowledge on the JVM is fundamentally wrong, no shared data
structure can beat a TLA in terms of access costs. But at which point
s
On Mon, Jan 6, 2020 at 7:09 PM Matt Sicker wrote:
> Would it be useful to implement some sort of buffer pool for
> StringBuilders and ByteBuffers? Could likely copy code from netty's
> util library (ByteBuf et al.) or reuse stuff from commons-pool if
> needed. This would work properly in applicati
On Tue, Dec 24, 2019 at 10:48 PM Volkan Yazıcı wrote:
> In its current form, LogstashLayout can (almost) very well render the
> GELF layout[1]. There are only two shortcomings: 1) epoch seconds with
> fraction and 2) using PatternLayout while rendering messages. But no
> worries, I will address th
