On Thu, 2007-12-27 at 16:00 -0500, Tim Julien wrote: > All, > Hi Tim
> I am in the process of migrating from HttpClient 2.x to HttpClient 4.x. > (This is for Limewire) > > Is there a migration guide anywhere that helps you go from the "old" > stack to the new one based on HttpCore? > There is unlikely to be a migration guide until new API is frozen (HttpClient goes BETA1) > I think I've banged my way through it pretty well but I'm struggling > with how to close connections (or at least tell the connection manager > that i'm finished - close if not maintaining persistent connection). On > the old stack I could do this: > > org.apache.commons.httpclient.methods.GetMethod get = .... > // make a connection > get.releaseConnection(); > > Under the new stack I'm not totally clear. > > I've seen the example at: > http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/module-client/src/examples/org/apache/http/examples/client/ClientConnectionRelease.java > > But based on that, the only method available to me on the request object > is abort() - which seems like it is only to be used when an unexpected > error occurs (RuntimeException). > > In the finally block of that example it says all you have to do to close > a connection is call response.getEntity().getContent().close(). Other > places seem to indicate I could alternatively call > response.getEntity().consumeContent(). > > Is close()'ing or consumeContent()'ing an HttpEntity enough to release a > connection? > Absolutely. HttpClient will automatically release the underlying connection in case of an I/O or runtime exception. The only situation HttpClient may be unable to automatically release the connection is when the response content is not fully consumed. In this case one should call #abort() on the request object. > Are there other ways (What if I don't have an HttpEntity)? It's a neat > trick that "closing" the HttpEntity has the side affect of releasing the > connection - but it's a little confusing if thats the best practice for > releasing a connection. > Yes, it is. Having to call #releaseConnection() in a finally clause was much complained about. There is no longer need to micro-manage connections as long as the caller always consumes the response body. > I also see that *if* I could get a reference to > org.apache.http.HttpConnection then I could call close(). > Or if I could get org.apache.http.conn.ManagedClientConnection I could > call close() or releaseConnection(). However, those aren't super easy > to get a hold of: > Actually, we do not want to provide the end users with an easy way of getting hold of the connection object primarily to make sure the connection is an consistent state when released back to the manager. > org.apache.http.client.HttpClient client = new DefaultHttpClient(); > org.apache.http.client.methods.HttpGet get = new HttpGet(myURL); > // client.execute(get), do some work > // ... > > // now lets close the connection: > org.apache.http.HttpHost host = new HttpHost(get.getURI()); > org.apache.http.conn.HttpRoute route = new HttpRoute(host); > org.apache.http.conn.ManagedClientConnection connection = > client.getConnectionManager().getConnection(route); > > connection.releaseConnection(); > > thx! > Hope this helps Oleg > -Tim Julien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
