User complaints of slow J2EE pages - log4j SMTPAppender

Performed a thread stack dump and during slow user performance and saw many threads waiting on log4j appender locks. It turned out that these were due to two separate causes: SMTPAppender backups due to a congested/slow smtp server and VMWare VMFS congestion.

Analysis revealed that the default behavior for log4j logging is synchronous. This is ensures the best chance that if the VM dies logging is likely to have been written and not lost because it was queued up in buffers.

FileAppender and ConsoleAppender extend from WriterAppender which can be set immediateFlush(false) to append asynchronously. It is reported that this might yield as much as a 20% increase in performance, however you risk losing important forensic logging if a crash occurs.

There is an AsyncAppender that can be plumbed in. It creates a queue and another thread that will asynchronously log to other appenders. This is useful for appenders like the SMTPAppender that does not extend from WriterAppender and does not have an internal asynchronous mode.

To plumb in the AsyncAppender instantiate an AsyncAppender and specify one or more appender-refs as the target appenders to be logged to asynchronously, i.e., SMTPAppender. Configure category and root logging to go to the ASYNCAppender instead of the target appender.


<appender name="asyncAppender" class="org.apache.log4j.AsyncAppender">
<appender-ref ref="theTargetAppender"/>
<param name="BufferSize" value="512" />
<param name="Blocking" value="false" />
</appender>


Another post on the AsyncAppender and its thread death causing it to go synchronous again.

Comments

Popular posts from this blog

Sites, Newsletters, and Blogs

Oracle JDBC ReadTimeout QueryTimeout

Locks held on Oracle for hours after sessions abnormally terminated by node failure