Note that there are some explanatory texts on larger screens.

plurals
  1. POSending notifications to the client when a job completes
    text
    copied!<p>I am writing an internal web application using Spring MVC where a user will submit a set of jobs to be completed via a RESTful web service. Each job will only take a few seconds to complete but a user could submit dozens of them. I want the option to notify the user when each job completes. This will be deployed to a Tomcat 6 installation which somewhat limits my options as I will not have access to Servlet 3.</p> <p>I've never written something quite like this before and I'm not entirely sure how to go about it. I'm thinking I want to do some kind of long polling but, while it seems conceptually easy, I'm not sure how to implement it with Spring.</p> <p>My initial plan was to simply leave the connection open (if the user set the option to receive notifications), start the jobs in a separate thread, and when a job completed send a message to the request thread via a BlockingQueue and forward the message to the user. However, I'm thinking it might not be a good idea to leave the connection open that long. I also don't see a way for jQuery to start handling an AJAX response before it has completed.</p> <p>Another option is long polling. I saw that Spring 3.2 introduces a new feature to do this described <a href="http://blog.springsource.org/2012/05/13/spring-mvc-3-2-preview-adding-long-polling-to-an-existing-web-application/" rel="nofollow noreferrer">here</a>, but 1) I'm not sure if that relies on the async support in Servlet 3, 2) it isn't clear to me how to use it from that example (if someone could point me to a more thorough it would be appreciated), and 3) <a href="https://stackoverflow.com/questions/12238750/spring-3-2-long-polling-causing-spring-security-context-to-be-cleared">this</a> might prose a problem since I will be using Spring Security to lock this application down.</p> <p>So, I could implement my own long polling mechanism. Are there any best practices on how to handle this? I was thinking I could keep around a singleton ConcurrentMap with session ids as keys and messages in a BlockingQueue as values. Worker threads would put messages into the appropriate BlockingQueue and as a request for messages came in on a session it would remove from the blocking queue until some terminal messages was posted. But then there is the problem where what if the client never comes back to exhaust the message queue. How would it get cleaned out? I have a gut feeling that there is a better way to implement this but I'm not sure what that is. Could someone give me some guidance here?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload