Long Polling with Spring 3.2′s DeferredResult

In our last episode, the CEO of Agile Cowboys Inc had just hired a Java/Spring consultant by giving him the Porsche that he originally bought for his girlfriend. Being upset by the loss of her prize Porsche, the CEO’s girlfriend has told his wife of their affair. His wife, after cutting up the CEO’s suites has filed for divorce. Meanwhile the CEO has implemented a new ‘casual’ dress code at the office and the Java/Spring consultant has just arrived back from a spin in his new Porsche and is sitting down at his desk about to fix the TV company’s software… If this doesn’t mean anything to you then take a look at Long Polling Tomcat With Spring.

The Java/Spring Consultant has to fix the TV Company’s server resource problem before the next big game, and he knows he can do this by implementing Spring’s Deferred Result technique using the Servlet 3 specification as implemented on Tomcat 71

The first thing that the Java/Spring consultant does is to check the project’s pom.xml file. For an asynchronous Servlet 3 project, you must include the following dependency:


Next you must tell Tomcat that the Spring DispatcherServlet supports Servlet 3 asynchronous communications. This is achieved by adding the following line to your web.xml:


The complete DispatcherServlet configuration is:


Having sorted out the project configuration the Java/Spring Consultant swiftly moves on to the controller code. He replaces the Graduate Trainee’s SimpleMatchUpdateController with a new DeferredMatchUpdateController:

public class DeferredMatchUpdateController { 

  private DeferredResultService updateService; 

  @RequestMapping(value = "/matchupdate/begin" + "", method = RequestMethod.GET) 
  public String start() { 
    return "OK"; 

  public DeferredResult<Message> getUpdate() { 

    final DeferredResult<Message> result = new DeferredResult<Message>(); 
    return result; 

The new DeferredMatchUpdateController is fairly simple. Like the SimpleMatchUpdateController it contains two methods: start() and getUpdate(), which do exactly the same job as their simple counterparts. This makes this controller a plugin replacement for the SimpleMatchUpdateController. The big difference is that the getUpdate() methods creates an instance of Spring’s DeferredResult, which it passes to the new DeferredResultService before returning it to Spring. Spring then parks the HTTP request allowing it to hang until the DeferredResult object has some data to return to the browser.

public class DeferredResultService implements Runnable { 

  private static final Logger logger = LoggerFactory.getLogger(DeferredResultService.class); 

  private final BlockingQueue<DeferredResult<Message>> resultQueue = new LinkedBlockingQueue<>(); 

  private Thread thread; 

  private volatile boolean start = true; 

  private LinkedBlockingQueue<Message> queue; 

  private MatchReporter matchReporter; 

  public void subscribe() { 
    logger.info("Starting server"); 

  private void startThread() { 

    if (start) { 
      synchronized (this) { 
        if (start) { 
          start = false; 
          thread = new Thread(this, "Studio Teletype"); 

  public void run() { 

    while (true) { 
      try { 

        DeferredResult<Message> result = resultQueue.take(); 
        Message message = queue.take(); 


      } catch (InterruptedException e) { 
        throw new UpdateException("Cannot get latest update. " + e.getMessage(), e); 

  public void getUpdate(DeferredResult<Message> result) { 


Again, like its counterpart SimpleMatchUpdateService the DeferredResultService contains two methods:subscribe() and getUpdate()

Dealing with getUpdate(...), all it does it to add the newly created DeferredResult object to a LinkedBlockingQueue called resultQueue, so that it can be dealt with later when a match update is available.

The real work is done by the subscribe() method. First, this method starts the matchReporter, which feeds match updates into the autowired queue instance at the appropriate moment. It then calls the private startThread() method to start a worker thread. This is only started once and uses double check locking to ensure that this is done efficiently and without problems.

The thread’s run() method infinitely loops firstly taking a DeferredResult object from the resultQueue, if available, and then a Message object, representing a match update from the update queue, again if available. It then calls DeferredResult’s setResult(...) using the message object as the argument. Spring will now take over and the original long poll request will be completed and the data belatedly returned to the browser.

Note that in this sample code the run() method contains a while(true) loop. Whilst this technique simplifies the sample code, it’s not such a good idea when it comes to production code. One of the problems of using wayward, uncontrolled threads is that they stop Tomcat shutting down correctly and you usually have to use the good ol’ Unix kill command to stop your server. In production code it’s a good idea to include code to close worker threads like this down gracefully.

After a hard couple of hours work, the Java/Spring Consultant promotes his code to live, picks up the keys to the Porsche and takes off for a spin. The next Saturday, using Spring’s DeferredResult, the servers cope wonderfully: the users are happy, the President of the TV company is happy and the CEO of Agile Cowboys Inc is happy, although he has a nagging suspicion that he’s paid the consultant too much, but hey, it’s only money.

1When writing this blog I used Tomcat version 7.0.42

The code that accompanies this blog is available on Github at: https://github.com/roghughe/captaindebug/tree/master/long-poll

Related Whitepaper:

Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions

Get ready to program in a whole new way!

Functional Programming in Java will help you quickly get on top of the new, essential Java 8 language features and the functional style that will change and improve your code. This short, targeted book will help you make the paradigm shift from the old imperative way to a less error-prone, more elegant, and concise coding style that’s also a breeze to parallelize. You’ll explore the syntax and semantics of lambda expressions, method and constructor references, and functional interfaces. You’ll design and write applications better using the new standards in Java 8 and the JDK.

Get it Now!  

2 Responses to "Long Polling with Spring 3.2′s DeferredResult"

  1. Craig says:

    I prefer WebSockets to DeferredResult because they reduce network traffic and latency. The only cases where I might prefer DeferredResult are if I couldn’t use HTTPS (WebSockets don’t play nicely on browsers within restricted networks over regular HTTP) or I had a very low traffic site.

  2. Marco says:

    Even though it works in this case, double-check locking is really an anti-pattern and should be avoided. AtomicBoolean.compareAndSet would work better here.

Leave a Reply

− three = 6

Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books