|Home > Index > Apache Geronimo v2.0 Samples > Using Asynchronous HTTP Client|
Since a servlet is blocking, a normal HTTP communication makes the thread wait. So there is a possibility that all the threads in the pool can be used up. By using the Asynchronous HTTP Client framework (AHC javadocs), the thread can be released back into the pool and be made available for other purposes until the answer comes back. When the answer comes back, a callback is fired which then relays the response back to the client.
The async http client is to be used in conjunction with web containers that are configured for non blocking communication. CometProcesor with Tomcat and Continuation with Jetty are some good examples. This example uses Tomcat.
This document is organized in the following sections:
This example seeks to demonstrate the usage of the async http client by first configuring the Geronimo server. It then deploys an app which we shall call http-local-app on this configured server. Another webapp call http-remote-app is deployed on any other server. The servlet on the http-local-app delegates requests to the async http client and returns immediately. The async http client connects to the remote app and when it recieves a response, a callback is fired which relays the message back to the original response stream.
The AsyncServlet in this app uses the AHC and implements the CometProcessor interface. The CometProcessor will make it's event method invoked rather than the usual service method, according to the event which occurred. The event object gives access to the usual request and response objects, which may be used in the usual way. More information about this can be read here.
The servlet also generates a random delay time and a random http status code. Using the async client, it connects to a remote url and passes these randomly generated values to it. The remote url is initialized from the servlet's <init-param> value. Once the async client sends a request to the remote app, the servlet returns without waiting for a response from the remote app. This app has a callback listener which holds the CometEvent object. When it receives the answer from the remote app, it gets the original response from the event object and passes the message to it.
A simple servlet in this app reads the two request parameters delay and code. It sleeps for the amount of time specified in the delay. If the code is 200, it serves a file called dummy.html. For the status code 500, it does a divide by zero to throw a servlet exception. For other status codes, it sets the appropriate response code in the response.sendError(). It then returns. This simulates varous response times and return status codes from an external app. This app can be run on any other server and machine.
Use one of the following methods to configure your server. Little-G assemblies do not have a console.
Install a geronimo server with tomcat webcontainer and start it. Log onto the console by using system/manager as your credentials. Click on the "Web Server" link on the left hand navigation frame. Under "Add new:" section, click on "Tomcat NIO HTTP connector". Specify a uniquename for the connector and take all the default values. Save this configuration. Your new connector must be listed in the Network Listeners.
Now delete the TomcatWebConnector in the Network Listeners list so that all connections are made to the new Tomcat NIO HTTP connector.
TomcatWebConnectorgbean. The line would now look like this
<gbean load="false" name="TomcatWebConnector">
org.apache.geronimo.configs/tomcat6/<version>/car, add the following gbean
$geronimo_home/bin>./deploy.sh deploy samples\async-http\http-local-app\target\http-local-app-2.0-SNAPSHOT.war
The true powers of the AHC can be seen only when the app using it is stressed under a heavy load. The client stressing the app can be any multi-threaded simulating simultaneous HTTP requests.
To leverage the full potential of AHC, the Geronimo server running it and the 3 machines (machines running the client, the local app with AHC and remote server) in the test setup must be tuned. This is necessary because the AHC starts devouring sockets and making remote connections at the same pace at which it gets the requests. If more sockets are made available to it, the AHC spends less time waiting for existing ones to free up. The bottleneck now has been transferred to establishing connections rather than at a normal blocking servlet.
Here are some of the parameters that can be tuned.
ahcrequest.py local_machine http://remote_machine:8080 200
The following test results show a comparison between an AHC enhanced servlet and a normal blocking servlet. Each of these servlets are pounded by 16, 200 and 500 simultaneous requests. The output captured from the python script shows the response time for each request. These tests also demonstrate the significance of tuning the IP stacks. When none of the machines are tuned, the response time starts increasing as the number of threads start increasing. Executing a
netstat command shows that most sockets are either in TIME_WAIT or CLOSED_WAIT state.
Browse the sample code at http://svn.apache.org/viewvc/geronimo/samples/trunk/samples/async-http/
Check out code from svn using
svn co https://svn.apache.org/repos/asf/geronimo/samples/trunk/samples/async-http async-http
Browse the AHC code at http://svn.apache.org/viewvc/geronimo/sandbox/AsyncHttpClient
Check out code from svn using
svn co https://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient ahc
View AHC's javadocs at AHC javadocs