Been lurking and watching the thread, wanted to throw some comments out without fully following the thread. Take everything with a grain of salt.
log4j 1.2's AsyncAppender does a bit of this by calling all sorts of methods to force the lazy initialization of the event prior to the event being queued for processing by the worker thread. This can result in a lot of unnecessary work on the calling thread copying things like the MDC that might but might not be used in the eventual message formatting. Performing the rendering of the message on the calling thread is also not desirable since things like formatting floating point numbers can be surprisingly expensive. In some of my earlier design experiments, I was very fond of having the formatter/layout object supporting a two phase approach where the layout had an opportunity to "extract" from the logging event on the calling thread and then process the extracted information later on the worker thread. The extraction method would be responsible to assemble the information that it needed into an arbitrary immutable object that would be passed blindly by the framework to the formatting phase at the proper time. The implementation had the choice of whether it wanted to render all the way to String on the calling thread (say if it were cheap) on do the minimum to get immutable objects in the calling thread and do all the heavy lifting on the worker thread. Without getting the layout participating, you almost will be doing unnecessary work on the calling thread. I fleshed this approach out several years ago at https://svn.apache.org/repos/asf/logging/sandbox/experimental/pattern-layout if anyone wants to take a look for ideas. --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
