#java #scala #logging #actor #akka
#java #scala #ведение журнала #актер #akka
Вопрос:
В следующем документе обработчики событий описаны как заменяющие ведение журнала http://akka.io/docs/akka/1.2/general/event-handler.html
В Akka есть обработчик событий, который заменяет систему ведения журнала:
akka.event.EventHandler
В частности, по этой ссылке приведен пример того, как это сделать при использовании slf4j: http://akka.io/docs/akka/1.2/general/slf4j.html
Мой вопрос: «Какие преимущества это дает? «почему я должен делать это вместо того, чтобы просто использовать регистратор, используя стандартный шаблон?»
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
...
private static Logger log = LoggerFactory.getLogger(MyActor.class);
...
log.info("doing something");
Есть ли какая-то основная выгода, которую я бы получил, основываясь на потоковой передаче или внутренних компонентах диспетчера, используя обработчик событий поверх приведенного выше шаблона регистратора, который я не вижу? Если нет, использование обработчика событий для ведения журнала похоже на отклонение от знакомого шаблона без ясной причины.
Спасибо за любой вклад!
Ответ №1:
Ведение журнала обычно означает ввод-вывод, что может замедлить работу вашего кода. В контексте субъекта, где каждое сообщение должно обрабатываться одним файлом в вашем методе приема, эти накладные расходы могут в некоторых случаях приводить к разнице во времени (или более) во времени для завершения этого метода. В системах, основанных на Erlang, уже принято перемещать ведение журнала за пределы потока управления потоком (или процессом в сфере Erlang), который запускает блок приема. Если ваши участники не сильно зависят от времени получения блока приема, вы всегда можете вернуться к стандартному шаблону ведения журнала, если это упростит вам задачу, но, вероятно, хорошей идеей будет привыкнуть к подходу, основанному на EventHandler.
Комментарии:
1. Спасибо, Томас, это имеет смысл. Я пошел дальше и изменил ведение журнала в своих актерах, чтобы использовать EventHandler.info () и т.д. методы. Похоже, он не соответствует моему шаблону, указанному в моем log4j.xml файл, но я, по крайней мере, вижу свои сообщения на уровне ИНФОРМАЦИИ.
2. Асинхронное ведение журнала звучит немного опасно. Какая у меня есть гарантия, что а) операторы журнала выходят в правильном порядке и б) что обработчик событий может идти в ногу с остальной частью системы (если ведение журнала является самой медленной частью системы, очередь журналов будет просто расти и расти, пока не произойдет OutOfMemory). Имеет ли смысл регистрировать ошибки синхронно?
3. Если вы зависите от конкретной последовательности или гарантий упорядочения, возможно, подход, основанный на акторах, вам не подходит. Тем не менее, поскольку ведение журнала само по себе обрабатывается субъектом, а субъекты получают свои сообщения в том порядке, в котором они были получены, это не должно быть проблемой. Кроме того, Akka имеет очень надежную реализацию очереди сообщений, которая также настраивается / настраивается в соответствии с вашими потребностями. Если вы беспокоитесь о переполнении буфера (я не уверен, какие ограничения у Akka по умолчанию), вы можете использовать ограниченную очередь сообщений и создать свой собственный обработчик ведения журнала, который его использует.
Ответ №2:
@DParsin, в вашем пути к классу должен быть файл application.conf, содержащий, по крайней мере, следующее:
akka {
event-handlers = ["akka.event.slf4j.Slf4jEventHandler"]
loglevel = DEBUG
stdout-loglevel = INFO
}
и затем, конечно, также убедитесь, что вы используете logback (или slf4j-log4j и т. Д.).
Если у вас есть logback-classic-1.0.0.jar в вашем пути к классам убедитесь, что у вас нет других адаптеров SLF4J в вашем пути к классам.
Ответ №3:
Будьте осторожны с использованием Slf4jEventHandler в Akka 1.2. Вы теряете возможность устанавливать уровни ведения журнала для каждого класса по сравнению с
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
...
private static Logger log = LoggerFactory.getLogger(MyActor.class);
...
log.info("doing something");
Причина в том, что Slf4jEventHandler использует только один регистратор с именем «akka.event.slf4j.Slf4jEventHandler»