5

This is the issue I encounter, which is design and implementation related :

I have a REST web service that accepts POST requests. Nothing special about it. It currently responds synchronously.

However, this web service is going to initiate a background process that may take some long time.

I do not want this service to respond 30 minutes later.

Instead, it should immediately return an ack response to the client, and nothing more (even after 30 minutes, there will be no more information to send).

How do I implement such behavior with Jersey ?

I read the page https://jersey.java.net/nonav/documentation/2.0/async.html#d0e6914.

Though it was an interesting reading, I did not find the way to only send an ACK typed response (something like an HTTP 200 code).

Maybe i am confused with asynchronous and the behavior I want to implement.

I just understood that I could create a new Thread within my @POST method to handle the background process, and just returns immediately the ACK response.

But does this newly thread live after the response has been sent back to the client ?

How would you implement this WS ?

I hope you will help me clarifying this point.

Ajeet Ganga
  • 8,353
  • 10
  • 56
  • 79
jeromedt
  • 189
  • 2
  • 8
  • Why wouldn't your thread stay alive? I would just spawn a new thread since the result of this thread doesn't concern the client. – condit Jul 09 '13 at 17:40
  • @condit : I tried this approach : it works great. We will stick to it in a first iteration, but I am sure creating a new thread each time the WS is called could lead to some issues, right ? – jeromedt Jul 10 '13 at 07:43
  • You shouldn't create the thread directly. You'll want to use an `Executor` to create a thread pool. You could start with a fixed sized thread pool and tune it to your application. – condit Jul 10 '13 at 14:41

1 Answers1

5

I think the Jersey 2 Asynchronous Server API you linked would still hold the client connection until the processing completes. The asynchronous processing is really internal to Jersey and does not affect the client experience.

If you want to return an ACK, you can use a regular Jersey method, delegate the work to another thread and then return immediately. I'd recommend HTTP 202 for this use case.

You may create a Thread to do so just like in the Jersey 2 example and it would survive the execution of the Jersey resource method invocation:

@POST
public Response asyncPost(String data) {
    new Thread(...).start();
    return Response.status(Response.Status.ACCEPTED).build();
}

This being said, creating threads is generally not recommended within app servers.

If you're using EE7, I'd recommend you look at JSR-236 http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/package-summary.html

If you're using EE6, you can consider sending a message to a queue to be processed by a Message-Driven Beans (MDB) in the background.

TheArchitect
  • 2,161
  • 1
  • 12
  • 16
  • Thanks for your reply. I was a little bit confused by the use of asynchronous within Jersey. Your answer helped me understand that it is completely internal to Jersey. I tried a sample code last night which starts a new Thread within WS Jersey : it works perfectly. However you point that the use of threads is not recommended within app servers. We are using Tomcat 6, not a full JEE compliant server. Also you're suggesting an MDB implementation : is JMS a viable solution ? Thanks again for your time and your clear explanations. I will look into the link you provided. – jeromedt Jul 10 '13 at 07:46
  • JMS would work yes (assuming the consuming threads are pooled), that is what MDBs are built on top of, but JMS is also not part of the EE web profile so you probably can't use it with Tomcat 6 either unless you have an external MQ product available. If you can't upgrade to EE, I'd recommend to use http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ExecutorService.html at least. While it still would create threads outside of the container's purview, at least it provides you a framework for pooling and asynchronous handles on tasks via Futures. – TheArchitect Jul 10 '13 at 15:27
  • Indeed, same reply has been made on my question. Thanks for all the details you provided. Have a great day. – jeromedt Jul 11 '13 at 07:29