Учитывая, что я застрял с SLF4J и java.util.Logging, какое оптимальное решение?

Ситуация: мы используем SLF4j и Log4j 2 с асинхронными приложениями. Проблема в том, что мы также используем JSF, который использует java.util.Logging. Я вижу все виды отвратительных предупреждений о производительности в отношении использования jul-to-slf4j из-за того, что вы не можете просто выбросить java.util.Logging, потому что он находится в JDK, и потому что... вот что документация на http://www.slf4j.org/legacy.html говорит:

"... Следовательно, преобразование jul в SLF4J может серьезно увеличить стоимость отключенных операторов ведения журнала (в 60 раз или 6000%) и ощутимо повлиять на производительность включенных операторов журнала (общее увеличение на 20%). По состоянию на logback версии 0.9.25, с помощью LevelChangePropagator можно полностью устранить 60-кратные накладные расходы на перевод для отключенных операторов журнала."

Обратите внимание, что несмотря ни на что, с SLF4J + java.util.Logging вы застряли с падением производительности на 20%, но вы можете отказаться от 60-кратного увеличения, используя последнюю версию.

20 % неприемлемы.

Другие идеи приветствуются и поощряются, но решение, которое я имею в виду, состоит в том, чтобы просто не консолидировать java.util.Logging. Вместо этого используйте отдельный файл конфигурации, который указывает на тот же файл журнала, что и все остальное. Кто-нибудь знает или знает, где я могу найти пример того, как это сделать, предполагая, что это не будет означать конец всего творения?

Если есть лучший способ, я открыт для него.


log4j slf4j java.util.logging
person user447607    schedule 25.08.2013    source источник
comment
Вы можете отказаться от 60-кратного увеличения, только используя последнюю версию logback. Поскольку вы используете Log4j 2 в качестве конкретной реализации ведения журнала, это неверно в вашем случае и может быть еще одной причиной не использовать мост. Кроме этого, я не могу дать никаких советов о том, как это сделать, поскольку мне еще не приходилось иметь дело с j.u.l, и я надеюсь, что так оно и останется.   -  person sheltem    schedule 26.08.2013
comment
Да, я видел это, но на самом деле чуть дальше в документации я нашел место, где говорилось, что в последних версиях код из журнала был перенесен в SLF4J, и поэтому это больше не было проблемой. Но все равно застрял на 20%.   -  person user447607    schedule 26.08.2013

Ответы (1)


arrow_upward
1
arrow_downward

Я думаю, что оптимальное решение — взять на себя 20-процентное падение производительности. Если вы не полностью замените классы JUL, обработчик будет первым, когда LogRecord покинет JUL. Вам также потребуется написать собственную версию LevelChangePropagator, чтобы изменения уровня журнала (например, реконфигурация) в Log4J2 отражались в регистраторах JUL. (В противном случае 60-кратное попадание убьет производительность отключенных операторов журнала.)

Вы можете заменить классы JUL своими собственными (которые напрямую используют SLF4J или Log4J2), но, поскольку JUL не входит в список пакетов, на которые распространяется механизм переопределения одобренных стандартов Java, вы фактически говорите о работе на альтернативной JVM или закрытии к этому в сложности обслуживания.

Вы можете развернуть пользовательскую реализацию JSF, возможно, взяв версию с открытым исходным кодом и заменив все вызовы JUL вызовами SLF4J. Вы избежите падения производительности, и это будет не так сложно, как заменить JUL. Вы по-прежнему будете поддерживать вилку JSF, хотя, если вы ограничите свои изменения, возможно, поддержка вилки будет не так уж плоха. Это также не будет охватывать любой другой фрагмент кода, который вызывает JUL.

person Boyd Stephen Smith Jr.    schedule 29.09.2014
comment
Возможно, найдется огромное количество людей, которые оценят такую ​​вилку. - person user447607; 13.10.2014