On Tue, 2015-01-20 at 13:58 -0700, Graeme Wallace wrote: > Hi, > > We just starting using the Http Async client package last month. > > So far its worked out really great in our development lab - thanks for all > the work that's been put into it ! > > I had some questions about best practices around configuring up the package > for a production deployment. > > We have a farm of machines that we use to make requests to airline and, > online travel agency APIs > One user search on our site may result in us having to make requests to 10 > or more vendors to gather back different priced itineraries. > > My thinking on this so far has been to use a ExecutorService to handle > a) building the HTTP request that is then delegated thru Async Http Client > b) process the response once it has been read > > In order to do b), i have another ExecutorService that is dedicated to just > reading the > HttpResponse. So when the FutureCallback::completed method is called it > simply wraps > the HttpResponse in a Runnable and throws it to the ExecutorService. The > idea being > that the IOReactor threads would then be decoupled from having to process > the actually IO. > > Does this make sense ? >
Yes, it does. The downside of this approach is that content of HTTP messages must be buffered in memory. > One the content is read its thrown to the original ExecutorService for > final processing and the results > meander their way back to the user. > > Assuming i haven't missed the mark. > > What sizes should i make the IOReactor thread pool size, The number of CPU cores, which is default anyway. > and my reading > response executor service ? Hard to say. It probably really depends on how may concurrent response messages the system must be able to handle. Hope this helps Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
