Asynchronous Request Dispaching, Part 2

This is part two of my previous blog where I said I would discuss the differences between WebSphere’s Asynchronous Request Dispatcher and the Asynchronous Servlet Proposal from the Java Community Process.

The initial Servlet EG proposal introduced a different model of asynchronous servlet processing through suspend, resume, and complete methods. The basic idea is to allow a servlet to initiate asynchronous operations and re-dispatch to the same servlet once these operations are complete. A suspend tells the container to disable the response so that additional logic in the initial dispatch doesn’t affect the response. Meanwhile, the application programmer uses another thread to do some asynchronous work required by the request. Once that is complete, resume is called which tells the container to schedule a dispatch of the request back through the filters and servlets. Alternatively, complete can be called to simply close the output without a re-dispatch. This has been debated thoroughly, and there are still competing proposals which are arguably less powerful. However, since this is the only publicly discussed proposal, I will use that for comparison.

I will present a few scenarios and show the way they can be solved in ARD and the Servlet EG proposal. This should help you understand the pluses and minuses of using one paradigm over the other.

Example 1: A request needs to print out a table that will be filled in with the results of two slow queries to external resources.

EG Proposal:

1. Original servlet prints out the table up to the point query 1 results are required

2. Suspend the request

3. Kick off query 1

4. Resume/re-dispatch the request after query 1 completion

5. Write results of query 1

6. Write next portion of the table

7. Suspend the request

8. Kick off query 2

9. Resume/re-dispatch the request after query 2 completion

10. Write results of query 2

11. Finish writing the table from the original servlet

ARD:

1. Original servlet prints out the table up to the point the query results are required on thread 0
2. Do async include on thread 1 to the servlet that does query 1
1. Concurrently, thread 0 continues writing the table
3. Do async include on thread 2 to the servlet that does query 2
1. Concurrently, thread 0 continues writing the table
4. Thread 1 returns and flushes content to the client up to query 2
5. Thread 2 returns and finishes the response

ARD Advantages:

1. ARD can finish sooner because query 1 and 2 are running simultaneously. The EG Proposal kicks them off 1 at a time.
2. With the EG Proposal, the application programmer could emulate query 1 and 2 running simultaneously, but they would have to do their own threading.
3. With ARD, the original thread can write out the full outline of the page because the container has the smarts to go back in and find the correct position for the response content. The EG Proposal does not.
4. The EG Proposal would have more issues with tracking state because the resume goes back through the filter and servlet request handling methods. The filters and servlets would have to make sure they are not duplicating output that was written before the initial or subsequent suspend.
5. Order of completion is not important when using ARD.

ARD Disadvantages

1. ARD only allows asynchronous operations inside of includes.
2. More threads are used.

Example 2: A request requires the results of two slow queries to external resources where state from query 1 is required for query 2 to work.

EG Proposal:

1. Enter the original servlet
2. Suspend the request and kick off query 1
3. Resume the request after query 1 completion
4. Re-enter the original servlet
5. Suspend the request and kick off query 2 with state from query 1
6. Resume the request after query 2 completion
7. Re-enter the original servlet and finish

ARD:

1. Enter the original servlet using thread pool A.
2. Do async include using thread pool B to the servlet that does query 1

1. Concurrently, the original servlet processing continues

3. Thread from thread pool A waits for results from query 1.
4. Do async include using thread pool B to the servlet that does query 2
5. Query 2 returns and finishes the response

ARD Disadvantages:

1. Because ARD does not have the ability to re-dispatch, we end up blocking the original thread to wait on the results of query 1.

From these examples, I conclude that ARD is best used for executing requests that each have multiple asynchronous operations that are independent of one another. Also, the context propagation that ARD provides is an added benefit. Similar context propagation may be introduced as an additional specification in Java EE 6, but it will not likely be a prerequisite for asynchronous servlets.

There are certain caveats that should be considered in both the ARD and RRD features and they are not one size fits all solutions. Feel free to check out details in the Information Center. There is also a good article on RRD at Developer Works.