2

Situation: We use SLF4j and Log4j 2 with asynchronous appenders Problem is we also use JSF which uses java.util.Logging. I see all kinds of heinous warnings about performance in regards to using jul-to-slf4j due to the fact that you can't just chuck out java.util.Logging because it's in the JDK and because... well here is what the documentation at http://www.slf4j.org/legacy.html says:

"...Consequently, j.u.l. to SLF4J translation can seriously increase the cost of disabled logging statements (60 fold or 6000%) and measurably impact the performance of enabled log statements (20% overall increase). As of logback version 0.9.25, it is possible to completely eliminate the 60 fold translation overhead for disabled log statements with the help of LevelChangePropagator."

Note that no matter what, with SLF4J + java.util.Logging you are stuck with 20% performance hit, but you can ditch the 60 fold increase by using a recent version.

20% is unacceptable.

Other ideas are welcomed and encouraged but the solution I have in mind is to simply not consolidate java.util.Logging. Instead, use a separate configuration file that points to the same log file as everything else. Does anyone have or know where I can find an example of how to do this, assuming doing so won't mean the end of all creation?

If there's a better way, I'm open to it.

user447607
  • 5,149
  • 13
  • 33
  • 55
  • You can only ditch the 60 fold increase by using a recent version of *logback*. Since you are using Log4j 2 as the concrete logging implementation, that isn't true in your case and might be another reason not to use the bridge. Other than that, I can't offer any advice on how to do it, since I've had the good fortune of not having to deal with j.u.l yet and I hope it stays that way. – sheltem Aug 26 '13 at 07:50
  • Yup, I saw that but actually a little further on in the documentation I found a spot where it said that in recent versions, the code from logback was brought into SLF4J and so it was no longer an issue. Still stuck with 20% though. – user447607 Aug 26 '13 at 17:58

1 Answers1

1

I think the optimal solution is to take the 20% performance hit. If you don't completely replace the JUL classes, a Handler is the first time a LogRecord leaves JUL. You'll also need to write your own version of LevelChangePropagator so that changes to log level (e.g. reconfiguration) in Log4J2 are reflected in the JUL loggers. (Otherwise the 60x hit will murder performance of disabled log statements.)

You could replace the JUL classes, with your own (that use SLF4J or Log4J2 directly), but since JUL isn't on the list of packages covered by Java Endorsed Standards Override Mechanism, you are effectively talking about running on a alternate JVM or close to it in maintenance complexity.

You could roll a custom JSF implementation, probably by taking the open source one and replacing all the JUL calls with SLF4J calls. You'd avoid the performance hit, and it wouldn't be nearly as difficult as replacing JUL. You'd still be maintaining a JSF fork, although if you limit your changes maybe maintaining the fork wouldn't be too bad. It wouldn't cover any other piece of code that are calling JUL, either.

Boyd Stephen Smith Jr.
  • 3,182
  • 14
  • 39