log4j Rolling file appender - проблемы с многопоточностью?

Question

Есть ли какие-либо известные ошибки с приложением прокатки файлов Log4J. Я счастливо использовал log4j в течение нескольких лет, но не знал об этом. Мой коллега предполагает, что существуют известные проблемы (и я нашел одну запись в Bugzilla по этому вопросу), когда при большой нагрузке приложение скользящего файла (мы используем основанное на времени) может работать некорректно, когда обновление происходит в полночь .

Запись Bugzilla - https://issues.apache.org/bugzilla/show_bug.cgi?id=44932

Цените вклады и советы о том, как другие преодолевают это.

Спасибо, Manglu

Answer 1

Я не сталкивался с этой проблемой сам, и из сообщения об ошибке, я подозреваю, что это очень редко. Th Log4j RollingFileAppender всегда работал предсказуемым и надежным образом для приложений, которые я разрабатывал и обслуживал.

Эта конкретная ошибка, если я правильно понимаю, произойдет, только если есть несколько экземпляров Log4j, например, если у вас одновременно запущено несколько экземпляров одного и того же приложения, записывающих в один файл журнала. Затем, когда наступает время пролонгации, один экземпляр не может заблокировать файл, чтобы удалить его и заархивировать его содержимое, что приведет к потере данных, которые должны были быть заархивированы.

Я не могу говорить ни с какими другими известными ошибками, о которых упоминал ваш коллега, если вы не хотите их конкретно цитировать. В целом, я считаю, что Log4j надежен для производственных приложений.

Answer 2

@ кг, это тоже случается со мной.Это точная ситуация.2 экземпляра одной и той же программы.Я обновил его до более новой версии roll.FollingFileAppender вместо использования DailyFileRoller (как бы он ни назывался).

Я запускаю два экземпляра одновременно через crontab.Экземпляры выводят столько сообщений, сколько они могут, пока не будет достигнуто 5 секунд.Они измеряют время в течение 1 секунды, используя System.currentTimeMillis, и добавляют счетчик для оценки 5-секундного периода времени для цикла.Так что в этом тесте есть минимальные накладные расходы.Каждое выходное сообщение журнала содержит инкрементный номер, а сообщение содержит идентификаторы, установленные из командной строки, чтобы можно было их разделить.

При составлении порядка сообщений журнала один из процессов успешно записывает от начала до концапоследовательности, другой теряет первые записи своего вывода (начиная с 0).

Это действительно должно быть исправлено ...