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.


> Mike Ahlers

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

View raw message