Somebody just pointed out that AsyncContext.start() is a way to start a thread from within a Web Container. I am wondering what is the intended use-case for which this call was added to Java EE?
1 Answers
AsyncContext.start() is unlikely to start a new thread. It will almost certainly use a container thread (from the same thread pool used to process requests). Tomcat, for example, will always use a container thread from the request processing thread pool.
The use case is anything where you don't want the 'main' thread to have to wait for whatever you put in the Runnable to complete before the main thread can continue.
Most of the examples I can think of are rather contrived but if you had some sort of messaging application implemented using Servlet 3.0 async with 5 connected clients the main thread might iterate through the AsyncContext's of each of the 5 clients and call start() on each context to send a broadcast message. That way the main thread is not held up by a slow client.

- 16,339
- 1
- 39
- 60
-
hi, thanks for your answer. however, there isn't sufficient justification or evidence for the 2 points you make: #1: intended for work that will complete reasonably soon; and #2: almost certainly use a container thread. #2 is a reasonable consequence of #1, so the key question remains: how do we know that was indeed the intended use case? .start() is as general as it gets in terms of starting a thread; and there is no hint in the documentation that it is expected to be short-lived; so a general way to start a thread allows that the designers intended started arbitrary long-lived threads – necromancer May 08 '12 at 20:18
-
#1 is not a point I made, #2 is stated in the specification and since there are no obvious benefits of using a separate thread pool that is what most (all?) containers do – Mark Thomas May 09 '12 at 06:52
-
i thought a pool implied short-lived. but i will read up more in the specification. – necromancer May 09 '12 at 18:18
-
The whole point of the async API is to make more efficient use of threads. The important thing is not how long the takes to run but that the thread is doing useful work. Generally, the tasks are short but they don't have to be. The reason for using container thread pool is that it puts an easily controllable upper bound on the number of concurrent threads doing useful work. Without that, it would be easy to overload the server. – Mark Thomas May 09 '12 at 18:43