I haven't thought too much about an interface yet, though having it work in such a way as to still allow thread local values to be used as one strategy would be a good design goal. Allowing for a more advanced object pool implementation as some sort of optional dependency or module could work there.
Your idea about using an MPMC queue for the object pool was essentially what I was thinking, though we can likely just reuse existing object pool implementations to avoid reinventing the wheel here. As for what the pool needs to allocate and manage, I'd expect that to either be Java-level buffer classes like StringBuilder, ByteBuffer, and potentially CharBuffer, or some sort of abstraction around those classes (e.g., we have ByteBufferDestination and StringBuilderFormattable from what I recall). A nice bonus of the resource pooling idea is that asynchronous appenders could still work in garbage free mode without overloading the system with OOM errors or having overly complicated book-keeping code. On Thu, 9 Jan 2020 at 07:22, Volkan Yazıcı <volkan.yaz...@gmail.com> wrote: > > On Thu, Jan 9, 2020 at 12:33 AM Gary Gregory <garydgreg...@gmail.com> wrote: > > Can we please not invent yet another pooling mechanism at Apache? > > That definitely was not my intention. I was just suggesting borrowing > code (not dependency!) from certain projects to get us going, since, > to the best of my knowledge, log4j-core is thriving to stay dependency > free. (@Ralph has made the very same remark as well.) > > In any case, I still did not hear anything about the *interface* we > want to make accessible within the Log4j code base. (@Matt?) How am I > gonna claim a char[] of certain length? What about a StringBuilder? > How are we gonna introduce control knobs to tune pool size(s)? > > In LogstashLayout, I dealt with these issues in an unpleasant way: > each pool had its own configuration knob. While this worked okayish > for LogstashLayout -- since I needed ~3 pools in total -- I am pretty > sure it will turn into a configuration nightmare for bigger code > bases, e.g., log4j-core. -- Matt Sicker <boa...@gmail.com>
