并发log4j [英] concurrent log4j

问题描述

我有我自己的日志记录引擎，它将日志写在具有阻塞队列的单独线程上。为了使用标准软件，我正在考虑切换到log4j。

我不希望我的高并发软件被减慢的日志命令一切到磁盘的一些作为命令被调用。 log4j是否可以用作转储程序？

解决方案

Log4j是大多数JavaEE应用服务器上的日志实现，因此对于并发能力来说是一个很好的广告。 / p>

说完之后，我在高负载条件下看到Log4j 1.2死锁。有一点调查强调了源代码中的一些可怕的错误同步。显然，这是固定在Log4j 1.3，虽然在这方面的发展已减缓或完全停止 - 我得到的感觉大部分来源是不可救药。

但是，可以自由选择，那么您应该考虑 Logback ，而不是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 everything 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.

这篇关于并发log4j的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！