0

I'm just porting some code over from .net to Java. I've been using the AsyncHttpClient (https://github.com/sonatype/async-http-client) library with the Netty provider.

Doing a little bit of testing I was surprised to see that during the execute call e.g:

httpClient.prepareGet("http://bbc.co.uk").execute(
                  new AsyncCompletionHandler<Response>() { ... });

The NettyAsyncHttpProvider performs a bootstrap connect to the site i.e.:

bootstrap.connect(new InetSocketAddress(
                                        AsyncHttpProviderUtils.getHost(uri), 
                                        AsyncHttpProviderUtils.getPort(uri)));

EDIT: to clarify the NettyAsyncHttpProvider class is part of the AsyncHttpClient Library. It has nothing to do with Netty itself.

Which means on something like the bbc website (on my lowly connection) it takes about 300ms for the execute to complete (then the async receive/complete happens almost immediately). This really kills the performance of my dispatcher which is trying to start multiple async calls. When each call is to the same domain it works well. In my situation I have hundreds of different domains so each call incurs the initial delay while the connection is established which kills the throughput of the dispatcher.

Can anyone offer any advice on how to use this library so it truly works in an async fashion or an alternative library?

Thanks, Paul

Paul
  • 655
  • 1
  • 8
  • 19

2 Answers2

2

To answer my own question...in the end I tried the original AsyncHttpClient library, Jetty and the Apache HttpAsyncClient (http://hc.apache.org/httpcomponents-asyncclient-dev/index.html) to try and find a library that is 100% asynchronous.

As far as I can tell each of these libraries performs a blocking connect before performing the actual http request asynchronously.

In order to move forward I've gone with executing each http request in its own thread. I've followed the pattern outlined in section "2.9. Multithreaded request execution" (http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html) that details how to use this approach.

This approach is now working well and allows the my "dispatcher" to rapidly create numerous async calls without having any blocking in the main thread.

Paul
  • 655
  • 1
  • 8
  • 19
  • Is this still the best solution around? Much of the point of async libraries is to avoid spawning multiple threads. This workaround defeats its purpose. – Nilzor May 30 '14 at 08:49
0

Yes, have you looked at the java non-blocking api? (a.k.a NIO)? There is a stack overflow thread about it which is useful. Also this article by IBM developerWorks should help you figure out if it's what you need.

Community
  • 1
  • 1
Ali
  • 12,354
  • 9
  • 54
  • 83
  • Hi Ali, I was under the impression that these libraries were using NIO already. – Paul Aug 12 '11 at 14:44
  • Not sure about Netty, but Grizzly says plain as day on its site that it uses NIO. – Ali Aug 12 '11 at 14:57
  • 1
    Yeah, so does Netty. The synchronous call isn't happening in Netty though. It's happening in the AsyncHttpClient library. I'm updating the question to clarify this. – Paul Aug 12 '11 at 15:03
  • 1
    My search continues. I've tried the HttpClient in Jetty and it does exactly the same thing. It seem that doing the socket.connect in the calling thread is the java pattern for some reason. I'm new to Java so I wouldn't want to say it's fundamentally wrong....but. For now I'll create a thread per call and do a synchronous http call within each worker thread. The offending jetty code is on line 100 [link](http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty.aggregate/jetty-all/7.4.0.v20110414/org/eclipse/jetty/client/SelectConnector.java#97) – Paul Aug 16 '11 at 11:40