Yes, I figured that myself too. This is exactly why I am creating this client for performance test purposes. I already created a similar blocking HTTP client but that is not suitable for every scenario.
On Fri, Nov 22, 2013 at 11:33 AM, Oleg Kalnichevski <[email protected]>wrote: > On Fri, 2013-11-22 at 11:27 +0200, Petteri Hentilä wrote: > > Thanks. I will try your suggestion later. > > > > The reason I am using non-blocking HTTP client is that I will use the > > client in a test where there are lots of concurrent long-polling HTTP > > connections. In a blocking HTTP client one connection runs in one thread. > > But in my test there will be hundreds or even thousands of concurrent > HTTP > > connections open so I was thinking that using a non-blocking HTTP client > > might be a better idea. > > > > Fair enough. A selector based I/O model is a better fit for scenarios > where one needs to handle thousands of concurrent connections that are > not constantly busy pumping data. > > Oleg > > > > > On Fri, Nov 22, 2013 at 11:13 AM, Oleg Kalnichevski <[email protected] > >wrote: > > > > > On Fri, 2013-11-22 at 10:55 +0200, Petteri Hentilä wrote: > > > > Hello, > > > > > > > > I'm creating my own asynchronous HTTP client with for performance > testing > > > > purposes. I am thinking of using Apache's CloseableHttpAsyncClient > for > > > this. > > > > > > > > Here is an example how to use this client: > > > > > http://hc.apache.org/httpcomponents-asyncclient-4.0.x/quickstart.html > > > > > > > > With CloseableHttpAsyncClient there are three callback methods > > > completed(), > > > > failed() and cancelled(). The completed() -method gets the > HttpResponse > > > as > > > > a parameter and the failed() -method gets the Exception as the > parameter. > > > > > > > > However, I would also need an access to the HttpContext object in > all of > > > > these callbacks methods. HttpContext represents execution state of an > > > HTTP > > > > process. You can for example store any user related objects to > > > HttpContext. > > > > > > > > Basically what I need is to have an access to HttpContext at least > in the > > > > following three different situations: 1. When the Http response is > fully > > > > received 2. When an exception occurs (for example the target host is > > > down) > > > > 3. When a connection timeout occurs > > > > > > > > Does anyone know a way to achieve this? > > > > > > There is nothing that prevents you from passing HttpContext instance to > > > the FutureCallback as a constructor parameter. You might however want > to > > > use a custom HttpAsyncResponseConsumer implementation in order to have > a > > > complete control over the response processing. > > > > > > As a side note when comes to performance in terms of data throughput > you > > > might be better served by a blocking HTTP client: > > > > > > > http://wiki.apache.org/HttpComponents/HttpClient3vsHttpClient4vsHttpCore > > > > > > Oleg > > > > > > > > > --------------------------------------------------------------------- > > > 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] > >
