CODEWITHSUNDEEP
javaspringasynchronousthreadpoolthreadpoolexecutor
Klaus Native
Klaus Native

Reputation: 3509

Using Spring @Async and ThreadPoolTaskScheduler with pool-size=1

We have a service implementation in our Spring-based web application that increments some statistics counters in the db. Since we don't want to mess up response time for the user we defined them asynchronous using Spring's @Async: 

public interface ReportingService {

    @Async
    Future<Void> incrementLoginCounter(Long userid);

    @Async
    Future<Void> incrementReadCounter(Long userid, Long productId);
}

And the spring task configuration like this:

<task:annotation-driven executor="taskExecutor" />
<task:executor id="taskExecutor" pool-size="10" />

Now, having the pool-size="10", we have concurrency issues when two threads try two create the same initial record that will contain the counter.

Is it a good idea here to set the pool-size="1" to avoid those conflicts? Does this have any side affects? We have quite a few places that fire async operations to update statistics.

Upvotes: 4

Views: 7064

Answers (2)

Jukka
Jukka

Reputation: 4663

Looking at the two examples you posted, instead of a constant stream of @Async calls, consider updating a JVM local variable upon client requests, and then have a background thread write that to the database every now and then. Along the lines of (mind the semi-pseudo-code):

class DefaultReportingService implements ReportingService {

    ConcurrentMap<Long, AtomicLong> numLogins;

    public void incrementLoginCounterForUser(Long userId) {
        numLogins.get(userId).incrementAndGet();
    }

    @Scheduled(..)
    void saveLoginCountersToDb() {
        for (Map.Entry<Long, AtomicLong> entry : numLogins.entrySet()) {
            AtomicLong counter = entry.getValue();
            Long toBeSummedWithTheValueInDb = counter.getAndSet(0L);
            // ...
        }
    }   
}

Upvotes: 4

John B
John B

Reputation: 32949

The side-effects would depend on the speed at which tasks are added to the executor in comparison to how quickly a single thread can process them. If the number of tasks being added per second is greater than the number that a single thread can process in a second you run the risk of the queue increasing in size over time until you finally get an out of memory error.

Check out the executor section at this page Task Execution. They state that having an unbounded queue is not a good idea.

If you know that you can process tasks faster than they will be added then you are probably safe. If not, you should add a queue capacity and handle the input thread blocking if the queue reaches this size.

Upvotes: 9

Related Questions