Welcome!

Java Authors: Michelle Drolet, Liz McMillan, Andreas Grabner, Elizabeth White, Pat Romanski

Related Topics: Java, Open Source, AJAX & REA

Java: Article

Asynchronous Logging Using Spring

Create applications that require high-volume logging without impacting an application’s performance

Each application developer faces the problem of logging usage information. On the one hand, the more logging that's done the easier it is to detect and locate the source of problems. On the other hand, large volume logging might impair an application's performance.

This problem is typically solved by defining various log levels dependent on a program's maturity. For example, a program in developmental stages would have a higher logging requirements; logging requirements would be relatively lower in the production phase. If an application requires a lot of logging for audit purposes, then special measures are required to protect performance.

This article provides a possible solution for this problem by using Spring asynchronous support.

Rationale for High-Volume Logging
Logging is used extensively to help find problems within applications. A developer who finds a problem can investigate it by enabling debug logging. He may then reproduce the problem, or create additional logging if needed. Programmers usually require extensive logging to locate problems.

However, the aforementioned process is not a universal solution. If a developer comes across a one-time event that does not happen again, then he has to uncover and fix the problem using only existing log data. For instance, a security problem should not be resolved by enabling full logging and waiting for another intrusion. Such cases require a lot of logging upfront.

Above and beyond the use of logging for application development, regulatory compliance requirements also demand a minimum amount of logging.

Possible Solutions
The simplest solution would be to log everything synchronously, right inside business logic methods. Of course this solution would reduce processing speed, but if an application does not have strict performance requirements, it might not be a problem.

A developer may also use some existing solutions, such as synchronous logging. Examples include log4j, AsyncAppender, and JMS. The latter is especially useful if none of the logging events should be lost.

Very often logging operations are not very fast because, for reliability purposes, these logs are often written either to a database or to a remote server. In addition, data may be subject to operations before they can be logged.

Consider a simple case when logging is needed, but performance should not be affected.

Please note that threads may not necessarily execute in the same order as they were called, so you'll have to sort the logged events by timestamp in order to have them in chronological order.

Spring 3.0 Asynchronous Support
Overview

Spring 2.0 provided a TaskExecutor abstraction that could be used for running asynchronous tasks. Evolution to version 3.0 enabled annotations to be used for this purpose. Refer to the Task Execution and Scheduling section in the Spring 3.0 documentation.

There are several built-in TaskExecutor implementations, and not all of them are asynchronous. For example, the SyncTaskExecutor invokes a task in the calling thread.

This article will concentrate on the ThreadPoolTaskExecutor - the most commonly used implementation in the Java 5 environment.

The ThreadPoolTaskExecutor provides the following configurable parameters:

pool-size: Defines the size of a pool; it also accepts a "core-max" range. The "core" is the initial number of threads in a pool; the "max" is the maximum number of threads. If only one number is defined, then the core and max are the same size.

Please note that the executor will first use the core number of threads, and then add threads to the pool only when the queue is full.

queue-capacity: Refers to the size of the task queue when all threads are busy. By default the queue is unlimited. That might lead to an OutOfMemory exception and disrupt the application, therefore, a specific queue size should be defined.

rejection-policy: A parameter that determines what should happen if both the thread pool and queue are full. In this case the task is rejected, and then the rejection policy determines what should happen to it.

The following policies are supported:

  • AbortPolicy: Executor will throw a TaskRejectedException
  • DiscardPolicy: Tasks will be skipped
  • DiscardOldestPolicy: Oldest tasks will be skipped
  • CallerRunsPolicy: Task will be executed in caller thread (synchronously)

Spring 3.0 allows bean configuration using both Annotations and XML. We will consider Annotation and XML configuration of TaskExecutors only.

Here is a simple business class that requires logging.

@Service
public class BankOperator {

@Autowired

private BusinessLogger businessLogger;

public void transferMoney() {

//... business logic for transferring money
// writing log
businessLogger.logMoneyTransfer(new Date(), "John", new BigDecimal(100));
}
}

As you can see the businessLogger has a specific method for a specific business operation. Developers always pass the current timestamp and a number of parameters. The timestamp is needed because the logging method will be invoked asynchronously at an arbitrary time in the future. The list of parameters will depend on what kind of logging is done. Usually this kind of logging is saved to a database, so developers need a number of parameters that will be mapped to the fields of the database table.

The maximum possible amount of operations should utilize asynchronous logging.

For example, if logging information depends on an account number, years of service and the balance of a bank account, then it's better to pass these three parameters to a logging method. The logging logic would be implemented, thereby, lessening the influence of logging on execution of the primary service.

XML - configuration
The configuration of ThreadPoolTaskExecutor looks like this:

<bean id="businessLogExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
<property name="corePoolSize" value="1" />
<property name="maxPoolSize" value="1" />
<property name="queueCapacity" value="1" />
<property name="rejectedExecutionHandler" ref="callerRuns" />
</bean>

<bean id="callerRuns" class="java.util.concurrent.ThreadPoolExecutor.CallerRunsPolicy"/>

Spring 3.0 enables developers to use the ‘executor' element to create a ThreadPoolTaskExecutor instance:

<task:executor id="businessLogExecutor"
pool-size="5-25"
queue-capacity="100"
rejection-policy="CALLER_RUNS"/>

The logger class might look like the following:

public class AsyncBusinessLogger implements BusinessLogger {

private TaskExecutor taskExecutor;


public void setTaskExecutor(TaskExecutor taskExecutor) {

this.taskExecutor = taskExecutor;
}

public void logMoneyTransfer(final Date timestamp, final String customerName, final BigDecimal sum) {

taskExecutor.execute(new Runnable() {
public void run() {
System.out.println("Customer '" + customerName + "' transfered $" + sum + " on " + timestamp);
}
});
}
}

A BusinessLogger may resemble the following:

<bean id="businessLogger" class="com.axmor.async.logging.AsyncBusinessLogger">
<property name="taskExecutor" ref="businessLogExecutor" />
</bean>

Using XML configuration is a more flexible approach. A developer can tell many Business Loggers to use the same TaskExecutor, or tell a single Business Logger to use multiple TaskExecutors.

@Async annotation
To use the @Async annotation, turn on task annotation support by including the following in config.xml:

<task:annotation-driven />

In this case, the ThreadPoolTaskExecutor with default settings will be used.

To use the aforementioned executor, insert the following instead:

<task:annotation-driven executor="businessLogExecutor"/>

The logger will look like the following:

@Service
public class AsyncBusinessLogger implements BusinessLogger {

@Async

public void logMoneyTransfer(Date timestamp, String customerName, BigDecimal sum) {
System.out.println("Customer '" + customerName + "' transfered $" + sum + " on " + timestamp);
}
}

The result is simpler and cleaner code. But a less flexible configuration comes at a price: all methods annotated with @Async will use the same TaskExecutor throughout the application.

@Async vs TaskExecutor: when to use
Using the @Async annotation is much simpler than having to wire the task executor to call tasks manually.

Usually the @Async annotation is the preferred method.

In cases where a developer doesn't want to use a single TaskExecutor for all asynchronous operations, which is the case for @Async annotation, he will have to use TaskExecutors.

Conclusion
Developers should strongly consider using asynchronous logging when creating applications that require high-volume logging without impacting an application's performance.

The article shows how easy it is to create your own custom asynchronous logging using Spring 3.0 Async support.

More Stories By Mylnikov Sergey

Mylnikov Sergey is a senior software engineer in the IBM Solution Group at Axmor Software. He has over seven years of experience in software development, as well as strong knowledge in Java SE/EE and web application development. He has been a technical lead and software architect in several successfully completed enterprise projects for US, UK, and Australian customers.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.