hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: NIO -- duplicate callbacks?
Date Thu, 23 Apr 2009 08:36:36 GMT
On Wed, Apr 22, 2009 at 03:54:47PM -0700, Chas Williams wrote:
> Hi all,
> I'm trying to use the httpcore NIO extensions to implement a large-scale
> non-blocking http client. I've done this by implementing the
> HttpRequestExecutionHandler interface, and my code is largely based off the
> sample client at
> http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/module-nio/src/examples/org/apache/http/examples/nio/NHttpClient.java
> .
> I asked a similar question to this mailing list a while back -- I had a
> difficult time trying to figure out which methods to hook into to ensure
> that I'll always respond to completed HTTP requests -- whether they succeed
> or fail in any number of ways (timeout, errors, etc). I found the
> documentation lacking at the time, and I see that it's been much improved
> since then, but it's still not clear to me which method (or set of methods?)
> will give me the behavior I'm looking for.
> My current solution for this is to implement connectionClosed method in the
> EventListener interface, and the cancelled, failed, and timeout methods in
> the SessionRequestCallback interface -- but it seems like every once in a
> while, one of my requests is returned (as an attachment) through more than
> one of these methods.
> Is the finalizeContext method of the HttpRequestExecutionHandler interface
> always called when a request is done, even if the request failed in any way?
> If not, how many other methods (in SessionRequestCallback and/or
> EventListener) do I have to implement, and which set will be called once
> (and only once) at the final stage of handling for a request?
> Thanks,
> Chas

Hi Chas

I do not think there is a problem with duplicate callbacks. The EventListener
was never meant for anything else but injecting some sort of simple event
logging. This is its only purpose. The real problem is that
AsyncNHttpClientHandler does not propagate #exception and #timeout events to
the NHttpRequestExecutionHandler. This is an unfortunate oversight on my part
for which I take full responsibility. It makes more difficult to handle errors
with NHttpRequestExecutionHandler implementations. Having said that, so far I
always found it possible to provide the necessary error recovery logic in the
#finalizeContext event. #finalizeContext is _always_ guaranteed to fire when a
connection has been closed (whatever the cause). So you can always rely on
either #handleResponse or #finalizeContext firing as a result of a submitted
request in the #submitRequest event. So far that worked for me. If we ever
encounter a situation where this guarantee is no sufficient we will have to
deprecate NHttpRequestExecutionHandler interface and replace it with something

Anyways, a few more closing notes:

(1) Consider implementing a custom NHttpClientHandler protocol handler as the
last resort. This would enable you to have a complete control over the process
of client-side http protocol handling at the expense of having to maintain a
bit more of custom code.

(2) There is another example you may find useful. This is in fact the
recommended way of doing asynchronous client-side HTTP:


Hope this helps


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

View raw message