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

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

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

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

Спасибо, Manglu


person Manglu    schedule 26.02.2010    source источник


Ответы (2)


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

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

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

person kg.    schedule 26.02.2010
comment
Привет, Константин! Это тоже было моим наблюдением. Я безопасно использую log4j в течение нескольких лет. Я проведу расследование и сообщу. Спасибо, Manglu - person Manglu; 01.03.2010

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

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

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

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

person Shorin    schedule 16.03.2011