I added comments on the JIRA, perhaps best to keep it all in one place in the JIRA, but I would not recommend making the synchronous route the default since it results in jumbled log files with events out of order. This used to be our default and nobody was happy with this. (It is a nightmare to try to make sense of an out-of-order log file.)
We can configure a different wait strategy for the Disruptor, but I recommend we raise this with the Disruptor maintainer, and give them all the details we have. On Sat, May 18, 2019 at 4:05 AM Carter Kozak <cko...@ckozak.net> wrote: > Absolutely, we already have a "discard" policy that works great! There are > certain types of events that I don't wish to throw away, even under very > heavy load. > > See > > https://logging.apache.org/log4j/2.x/manual/configuration.html#asyncQueueFullPolicy > > -ck > > On Fri, May 17, 2019, at 15:02, Gary Gregory wrote: > > Would it make sense to have an optional "drop events on the floor" policy > > when things get busy? > > > > Gary > > > > On Fri, May 17, 2019, 14:52 Carter Kozak <cko...@ckozak.net> wrote: > > > > > Hi friends, > > > > > > I've filed LOG4J2-2606 after tracking down the issue in prod. It's > > > frightening because the result was instability across entire box due > to CPU > > > starvation, caused by a full logging queue from heavy load. I'm > curious if > > > anyone else has run into this behavior. We may want to change the > default > > > policy to use the synchronous route rather than enqueue. This would > allow > > > for contention in other places, and allow certain threadlocals to be > > > initialized on application threads rather than being confined to the > > > background thread, however we already account for this when running in > > > synchronous mode and the current failure is pretty nasty. > > > > > > Thoughts or concerns? > > > > > > https://issues.apache.org/jira/browse/LOG4J2-2606 > > > > > > Thanks, > > > -ck > > > > > >
