vy commented on PR #3880: URL: https://github.com/apache/logging-log4j2/pull/3880#issuecomment-3190784094
> if flushing has stopped making progress altogether, e.g. due to a full or failed disk, then logging calls will block indefinitely. This can result in a production outage. If logging is a vital component of your application, and it doesn't work, I think it is reasonable to signal that the application is down. Consider this scenario in a cluster, say, Kubernetes, environment: container signals down in liveliness probes due to logging buffer failures, pod will be taken down, and re-spawned in a new environment with sufficient logging capacity. This is what you'd want, instead of losing all logging for an indefinite amount of time. I think this is a good default. If you indeed want the other way around, it makes sense that you need to opt-in for extra configuration, which is `log4j2.discardThreshold` in this case. @remkop, @ppkarwasz, WDYT? > More controversially, I think that `asyncQueueFullPolicy` should default to `Discard` for basically the same reasons. One weird thing about this is that the blocking queue-full policy is literally named `DefaultAsyncQueueFullPolicy` and is denoted by the property value `Default`. =\ This is a valid remark. I'd support a PR 1. renaming the default from `Default` to `Discard`, and 2. translating `Default` usages to `Discard` with a `WARN`'ing logged -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
