Now that Alex has an AsyncWeb subproject going, I've finally taken the time to look over the client code. I have some feedback about the client and what I would like to see change. We also discussed the client on IRC and I will summarize some of the things we talked about.
IoConnector Management - I really don't like how each AsyncHttpClient has it's own o.a.m.core.IoConnector instance which is used for a single connection. This has been discussed quite a bit but along the same vein, the IoHandler should also be a singleton and the state should be stored in the IoSession. Additionally, it should be possible to pass an instance of o.a.m.core.IoConnector so that the APR transport can be used (or any other transport that comes along for that matter.) Connecting - Connecting is done as a blocking operation. In Jeff Geneder's AHC branch in the Geronimo sandbox, thread pools are being used for asynchronous connecting. This is unfortunate since MINA already has this functionality and does it in a much lighter weight manner than using a thread pool. Completion Notification - With the existing AHC, there's a single callback for the Client. I REALLY like the observable future pattern that MINA uses. With each asynchronous operation, a future object is returned. This future object can be used to block until the operation completes. The future is also observable so you can also register one or more completion listeners with the future. This makes it real easy to do a fork/join like operation like: future1 = doAsynch1(); future2 = doAsynch2(); future3 = doAsynch3(); future1.await() future2.await() future3.await() or use an event driven approach like: doAsynch1().addListener(...); doAsynch2().addListener(...); doAsynch3().addListener(...); This provides maximum flexibility. This should be incorporated into AsyncWeb client. This topic came up on the IRC channel and David Lloyd (dmlloyd), Tuure Laurinolli (tazle), and I (mike_heath) were discussing better alternatives to the current design. The following is a summary of our conversation. David posted this mockup as a possible future API http://rafb.net/p/P8GLTg85.html David wanted me to be sure to note that the class names in the mockup are just for purposes of explanation may change. The AsyncHttpClient would hold the IoConnector implementation and default configuration. It would create HttpRequester objects that would use the IoConnector from AsyncHttpClient. This solves the IoConnector management problem I mentioned above. This pattern would also work with existing IoC containers. The HttpRequest object would then be used for sending the actual asynchronous request. It would get its default configuration from AsyncHttpClient. The HttpRequest could use keepAlive to pool connections to a particular host. When a request is sent, an HttpFuture object is returned. HttpFuture could be used for blocking until the request is done or an event handler could be registered. Special care needs to be taken to ensure that we can handle LARGE responses without loading the entire request into memory. We also need to provide an elegant way to deal with chunked-encoding in an event-driven fashion. We also discussed that all these classes should be interfaces and we will provide a default implementation of the interfaces. This gives us and users the flexibility to implement AsyncWeb client however we may want. A possible alternative name for AsyncHttpClient would be HttpConnector. David and Tuure please reply to this email with anything I may have missed or additional clarification. -Mike
