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]
