Re: NIO -- duplicate callbacks?

[Chas Williams <ch...@gmail.com>]

Oleg,

       I took a page from the design in
http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/httpcore-nio/src/examples/org/apache/http/examples/nio/NHttpClientConnManagement.java--
I now keep a set of in-progress requests (using my internal 'request'
objects), and allow callbacks in my HttpRequestExecutionHandler and
SessionRequestCallback implementations to 'complete' requests by removing
them from that set (subsequent callbacks for said object would have no
corresponding object in the set, and are ignored). Accordingly, I now use
the EventLogger callbacks for logging purposes only.
       This appears to have solved my problem. Thanks for your
feedback/help!

Chas


On Thu, Apr 23, 2009 at 1:36 AM, Oleg Kalnichevski <ol...@apache.org> wrote:

> 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
> else.
>
> 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:
>
>
> http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/httpcore-nio/src/examples/org/apache/http/examples/nio/NHttpClientConnManagement.java
>
> Hope this helps
>
> Oleg
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>