Queues are difficult to get right, and easy to deadlock, especially when there are multiple queues. Falling back to synchronous appender access avoids that risk and operates in the same threading model as synchronous logging. I've seen a bug roughly every 6 months (despite several billion log events per hour) which results in disruptor ceasing to process its queue. By using the synchronized mode I can ensure the stopped node doesn't time out all requests, and instead continues working more or less as expected.
For LOG4J2-2972 I might suggest a simpler approach, based on the feedback on the github issue the request was not to ignore thread death if we're logging synchronously in an application thread, our recent change would consume threaddeath on threads owned by the application if they happened to be logging at the time. If we rethrow ThreadDeath as a special case, it means that thread.stop on the background thread will prevent it from draining the queue, but I think that's fine. Thread.stop is deprecated and incredibly dangerous -- if it's called on a background thread and we recreate that thread, would that be any different from swallowing the exception? Carter On Fri, Dec 18, 2020, at 10:21, Volkan Yazıcı wrote: > Hello, > > While working on LOG4J2-2972 > <https://issues.apache.org/jira/browse/LOG4J2-2972>, I noticed that > AsyncAppender has a "sync" mode. The related code also necessitates access > to the ID of the running AsyncAppender task thread. I am sort of puzzled > regarding the following topics: > > *Why does an AA have a sync mode?* Yes, I read javadocs of > both EventRoute.SYNCHRONOUS and AsyncQueueFullPolicy. But again, why? If > the queue is full and we fallback to sync logging, doesn't this contradict > with the purpose of AsyncAppender? > > For LOG4J2-2972, I created an abstract executor which respawns the thread > upon unexpected termination. Though AsyncQueueFullPolicy.*getRoute() > asks for a thread ID*. This is difficult to get right with the executor > abstraction, and besides, made me question should getRoute() really ask for > it? > > I will appreciate your comments on these issues. > > Kind regards. >
