AppenderPitfalls

Pitfalls of purely synchronous and purely asynchronous (network) appenders

Synchronous appenders

Purely synchronous appenders, like Logbacks (or Log4Js) original SocketAppender, can be quite fragile creatures:

• slow receivers will slow down the whole logged application.
• it can't detect a stale event receiver. If a receiver is disconnected in a unclean way, the synchronous nature results in a total freeze of the logged application with no chance of escape
• the aforementioned appenders have no way to let receivers know that they are still "there" so receivers can't detect stale appenders either.

Asynchronous appenders

A simple asynchronous appender would probably just defer the handling of appended events which would be quite deadly:

• care must be taken to prepare events for asynchronous handling. In case of logback-classic this includes:
  • Evaluation of the thread name
  • optional creation of the CallLocation information (I missed that in my first version)
• it can't just accept any event that is appended, i.e. it needs event flooding countermeasures.
  • if the handling of the events (serialization, sending) is slower than the creation of new events it would result in an OutOfMemoryException
• it must be able to handle stale receivers, at least. Otherwise the application would still grind to a halt.
• Ideally, it should also implement a way to let the receiver know that it hasn't gone stale itself.

A mixed approach

My multiplex appender is using a mixed approach that is solving all mentioned problems. If you are really interested in the nasty technical details, just take a look at [MultiplexAppenderBackground].

I should mention, though, that it isn't ideal under all circumstances. Due to it's asynchronous nature it's possible that not all events are delivered in case of application-shutdown. You probably shouldn't use it for small command line tools and test-cases, for example.

The intended use-case is the logging of long-running applications like webapps.