hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Bursts of concurrent requests questions
Date Sun, 10 Aug 2008 17:06:26 GMT
On Fri, 2008-08-08 at 01:22 -0700, Mike Ahlers wrote: 
> Hi,
> 

Hi Mike,

> I am in need of handling burts requests and await the result of it, where
> the result is both capturing the http response code as well as minimal
> parsing of the body.
> 
> In the past, I've written a multi thread model which does this job, but have
> problems capturing the results properly, as I spawn threads, it sort of is
> done when these are all spawned. While I am only done when I have all the
> results. This should not block further requests (for burst requests) as
> well...
> 
> Now that a new core is out (NIO) and well into beta, I think it is a good
> moment to make use of that. But what would be the best way? I am talking
> about high volume, high preformance here as this component runs from server
> side (EJB container), and I don't want to run into max-connections as such.
> I want to know exactly what is shared and what isn't, to avoid
> max-connections.
> 
> Would the example mentioned:
> http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/module-client/src/examples/org/apache/http/examples/client/ClientMultiThreadedExecution.java
> 
> the proper approach? 

I am not sure about that. You really need to start thinking in terms of
asynchronous events fired within a certain session context rather than
linear executors. You would actually need threaded executors only if you
wanted to delegate request content generation or response content
processing to a separate worker thread.


> Where I want to wrap a single burst in an Executor
> thread model, each with its own ConnectionManager. How would I effectively
> wait the results and then 'finish' the method?
> 
> Before I go re-invent the wheel, I was hoping to receive some feedback from
> users who have experience in this use case.
> 
> All suggestions and pointers are welcome! Thanks in advance,
> 
> 

HttpCore implements only the very basic transport functions. For
HttpCore NIO to be useful for client side HTTP one needs to develop a
non-blocking connection manager similar to those that exist for
blocking HTTP in HttpClient 4.0. This involves quite a bit of work and
is far from being trivial.   

There are plans to initiate development of an NIO based version of
HttpClient, but I am somewhat hesitant to do it myself. HttpClient could
really benefit from having more contributors. An initial seed of the
asynchronous HTTP client code should ideally come from an external
contributor / another committer.

Oleg 


> 
> 
> Mike Ahlers


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


Mime
View raw message