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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
