Java HTTP Client - Comparison
Compare the features of the Oakland Software client to the other available HTTP clients. This is based on the current versions of these products as of June 2007, but we could be wrong. If there is a mistake here, please .
The publicly available HTTP clients are:
idle connection timeout - Most servers timeout connections after a certain interval. When HTTP clients use connection pooling, the fact that the connection was closed is detected when the next request is written to the connection. If it's an idempotent request (like a GET, or PUT) then it can just be retried on a new connection. However, POST cannot be retried (we don't know if it has been processed by the server or not), so the user of the HTTP client will get an error on this POST. The Oakland Software implementation provides a facility to terminate connections which have been idle for a (configurable) length of time, or alternatively to send a "ping" message before using a connection (if it has been idle for a certain amount of time). This ensures that POST requests will not be affected by the server connection timeout processing.
pipelining of requests - This allows multiple requests to be sent on the same connection before getting the response to the first one. This can make a tremendous performance difference when fetching many objects from the same server (as you don't have to pay the round trip latency for each request). This can also make a substantial throughput difference when in high volume applications by reducing the latency and sharing the socket connections for multiple requests at a time. The Oakland Software pipelining implementation is the only implementation that automatically handles all authentication modes before starting pipelining, allows pipelining for POST (useful in certain controlled environments), and automatically adapts to the server closing connections for maximum pipelining performance.
non-blocking I/O - In most HTTP implementations, the outstanding HTTP request ties up a thread until it is completed. This restricts the number of outstanding HTTP requests to the number of possible threads, which is a significant limitation (since each thread consumes a certain amount of memory). With non-blocking I/O the request can be sent and the response can be received on a different thread, thus an unlimited number of outstanding connections can be active with a small number of active threads. This support is useful for applications where large numbers of connections must be processed quickly. This (especially combined with pipelining and the use of direct reading and writing from the socket) give maximum throughput.
connection pool throttling - This is very useful in certain server situations. This is a limit on the number of connections to a given host and port. The HTTP 1.1 specification recommends that no more than 2 connections are established (to a given host/port). In any of the other implementations (that use connection pooling) it will open as many connections as you have requested. This can cause problems for some servers.
connection request timeout - A good timeout mechanism has three parts: timeout when establishing the initial connection, setting the TCP timeout on the connection (so that each request is subject to the timeout), and, if connection pooling is used, timeout while waiting for a connection to be available from the pool. The Oakland Software implementation is the only implementation that supports all of these.
true request/response streams - The older JRE implementations by default record the request data into a byte array and does not actually send the data until the connection is open. This results in double copying of the data, resulting in slower performance in cases where there is a lot of data. Other implementations allow you to read/write directly to the underlying connection stream, avoiding this double copy of the data. It also avoids reading this data if not required by the application, which is not possible if there is not a true response input stream.
After JRE 5, direct streaming to the output was implemented by adding new methods (setChunkedStreamingMode() and setFixedLengthStreamingMode()) however, these methods will not work if the connection requires authentication. The Oakland Software implementation will perform the authentication automatically before beginning the streaming processing so streaming works transparently with authentication.
NTLM - The JRE 1.4.2 supports NTLM only on Windows. The Oakland Software and Apache HTTP clients support NTLM on any platform. However only the Oakland Software NTLM support correctly supports both Unicode and OEM encoding for NTLM and supports NTLM V2. The Sun implementation in JRE 6 and 1.5_08 and higher support NTLM V2 on all platforms, though on Windows they use the current user's credentials by default.
plug compatible - This is true if you can switch to this HTTP Client from the Sun HTTP client without changing any code and it will just work. This means the HTTP Client implements the java.net.HttpURLConnection class, and the necessary protocol handlers for HTTP and HTTPS.
versions - JRE versions prior to 1.2.x and 1.3.x are supported only with version 1.x of the Oakland Software HTTP client. This includes all of the features except pipelining and Axis2 support. Version 2.x and higher of the Oakland Software HTTP client require JRE version 1.4.2 or higher.
medium turnaround - The Apache HTTP Client is supported as there are volunteers to work on it. Currently they offer pretty quick support, so long as you are willing to take their nightly builds. There have been periods though where no one was working on it, and this could be the case again. You can't be sure, but you can fix it yourself if you want.