开发者

concurrent log4j

开发者 https://www.devze.com 2023-03-07 11:07 出处:网络
I have my own logging engine which writes the logs on a separate thread with a blocking queue. For the sake of using \"standard software\" I am thinking about switching to log4j.

I have my own logging engine which writes the logs on a separate thread with a blocking queue. For the sake of using "standard software" I am thinking about switching to log4j.

I don't want my highly concurrent software to be slowed down by log commands that write every开发者_运维问答thing to disk as some as the command is called. Can log4j be used as a dumpster instead?


Log4j is the logging implementation on most JavaEE app-servers out there, so that's a good advert for its concurrency abilities.

Having said that, I have seen Log4j 1.2 deadlock under high load conditions. A bit of investigation highlighted some scarily bad synchronization in the source code. Apparently, this was fixed in Log4j 1.3, although development on this has slowed or stopped altogether - I get the feeling much of the source was unsalvageable.

However, if you're free to choose, then you should consider Logback instead, the spiritual successor to Log4j. It's a ground-up redesign, and is probably a better option for you.


Check out log4j's asynchronous appender, it buffers log messages ad passes them on to appenders using a separate thread. It might be that you decide the log4j async appender is not appropriate (here are some complaints about it), you could always make your own appender.

0

精彩评论

暂无评论...
验证码 换一张
取 消