#logging #log4j2 #spring-webflux
#ведение журнала #log4j2 #весенний веб-поток
Вопрос:
Хорошо известный факт, что мы не должны блокировать приложения Spring Webflux.
На конференциях SpringOne (2020 и 2020), а также на других конференциях несколько докладчиков подчеркнули важность также неблокирующего ведения журнала. Аргумент таков: бизнес-логика внутри Webflux может быть неблокирующей, но если выполненное ведение журнала блокируется, то оно блокируется.
Легко проверить, является ли уровень бизнес-логики неблокирующим, используя такие инструменты, как Blockhound и т.д…
Однако, как убедиться, что часть ведения журнала также не блокируется? Какие-либо инструменты? Рекомендации? У вас, ребята, есть какой-нибудь пример с log4j2? В качестве примера с pom, конфигурацией, log4j2.xml будет здорово.
Спасибо
Комментарии:
1. log4j2 поддерживает асинхронное ведение журнала. соответствует ли это вашим требованиям?
2. Здравствуйте, Мартин, у вас есть образец с pom, например, есть ли необходимость в дополнительных зависимостях, которые нам нужно принести, таких как disruptor jar? И какая конфигурация была бы необходима в файле log4j2? Требуется какой-либо параметр -D?
3. вы можете ознакомиться с официальной документацией log4j: logging.apache.org/log4j/2.x/manual/async.html
Ответ №1:
То, что предложил Мартин, верно. В соответствии с документом, использование org.apache.logging.log4j.core.async.AsyncLoggerContextSelector будет решением.
Я также вижу ссылки на LMAX disruptor.
Попробовал комбинацию обоих и протестировал BlockHound, ничего не блокируется.