1
votes

With Servlet 3.0 we can create tasks that are asynchronous operations allowing the thread handling the request to be returned to the container which can now use it to handle another request. If we are using a thread pool to configure the number of threads that can be used for asynchronous requests, how should that be tuned / what are the parameters that we should be considering?

It's also possible to tell spring to grab a thread from the ForkJoin pool and do the processing like this: (Taken from this tutorial:

    logger.info("Request received");
    DeferredResult<String> deferredResult = new DeferredResult<>();
    CompletableFuture.supplyAsync(taskService::execute)
        .whenCompleteAsync((result, throwable) -> deferredResult.setResult(result));
    logger.info("Servlet thread released");

When should we do this vs. the taking a managed thread pool approach with Callable? It almost looks as the only difference is that in one case we would probably want to configure Java 8s commonPool and Spring Boot would grab threads from there to do the above type of CompleteableFuture processing, and in the other it seems we would configure some type of ExecutorService for Spring. It almost seems like there's no difference int the approaches?

1

1 Answers

2
votes

For the first part i would suggest you to take a look at Chapter 8. Applying Thread Pools of "Java Concurrency In Practice" book.

For the second part - yes, spring executes Callable tasks on its own using provided thread pool, while DeferredResult should be processed by application. It provides more control, for example application can decide in runtime whether a particular computation should be run in a separate thread or not based on some metadata. DeferredResult also supports callbacks.