On Fri, 2010-08-06 at 17:58 -0700, Ken Krugler wrote: > Hi Oleg, ...
> > I'm trying to figure out how to map this advice onto what I've got in > Bixo: > > - I've got a bunch of fetch tasks being executed in threads using > Java's ThreadPoolExecutor. > > - Each task uses the same DefaultHttpClient with a > ThreadSafeClientConnManager to execute GetMethod requests. > > So when I decide that some of these fetch tasks need to be terminated: > > 1. What's the right way to get the list of active HttpUriRequest > objects that need to be aborted? I assume I'll need to keep track of > this myself, in some ThreadLocal storage. I don't see a way to get the > set of active requests back from either HttpClient or the connection > manager. > Hi Ken There is currently no reliable way of obtaining a list of all requests being executed by a HttpClient with a pooling connection manager. One could work the problem around by decorating the HttpClient interface and keeping track of request instances that are passed to the #execute method. The problem is that #execute method returns before the request/response exchange is fully completed, which makes this approach unreliable. A better alternative could be extending the pooling connection manager and providing a means of enumerating (or shutting down) all connections currently leased from the pool. > 2. I assume it's safe to call the HttpUriRequest.abort() method from > my main thread, while a worker thread is busy calling any method for > this same object (including abort) at the same time. > Yes, it is. AbortableHttpRequest#abort method implementations should be thread-safe. Hope this helps Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
