On Thu, 2008-12-18 at 11:33 -0800, TomStrummer wrote: > Hi, > > I'm working on a project that creates a simple HTTP client "builder DSL" for > the Groovy programming language > (http://groovy.codehaus.org/modules/http-builder/). Built on HttpClient 4. > > One feature I'm trying to add is a builder that automatically executes > requests asynchronously. This is easy to do (from a user standpoint) > because their response handling code is already packaged in a closure which > is easy to execute asynchronously. (think Prototype.js' Ajax.Request). > > So I have three questions: > > I'm looking at ThreadSafeClientConnManager and I'm wondering why it doesn't > use a java.util.concurrent ThreadPoolExecutor to allow for a dynamic pool > size?
ThreadSafeClientConnManager and ThreadPoolExecutor serve completely different purposes and are complimentary in their functions. The former manages a pool of objects, whereas the latter manages threads of execution. One can use ThreadPoolExecutor to execute multiple requests that obtain connections from a connection pool managed by ThreadSafeClientConnManager. > It looks like there are a number of classes in that package to handle > general concurrency and I'm wondering why the concurrent* library wasn't > used. > There is a plenty of references to standard java.util.concurrent primitives in the TSCM classes, as far as I can tell. > Is it true that HttpClient 4 already requires Java 1.5? > Yes, it is. > I'd also consider using NIO but from what I read in another thread, it's > inefficient unless you're talking thousands of simultaneous requests, > correct? The NIO model and the classic IO model have both advantages and disadvantages. The blocking I/O significantly outperforms NIO in terms of raw throughput on mainstream JVMs. However, in systems with high latency connections, worker threads can stay blocked in an input operation for many seconds or even minutes, which significantly degrades the system's ability to scale. With a great number of simultaneous connections the system can end up spending most of its processing time switching contexts of idle threads. So, one should use NIO where appropriate. HttpCore, the set of low level HTTP transport components HttpClient is based on, provides support for both blocking and non-blocking I/O models. Hope this helps Oleg > I'm not expecting my code to be used for anything like that :) > But I thought a flexible pool size would be a nice feature :) > > Thanks for the input. > > -Tom > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
