hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Back-to-back HTTP User Agent
Date Thu, 04 Jun 2009 11:55:03 GMT
On Wed, Jun 03, 2009 at 11:44:11PM -0700, J. D. wrote:
> I need a system with a back-to-back HTTP user agent:
> System Reqs:
> -----------
> 1) HTTP Server  accepts HTTP requests from user.
> 2) An unrelated (w.r.t. HTTP protocol i.e. no proxy semantics) HTTP Client 
> issues a request and elicit response from backend server(s) for request in (1).
> 3) Based on HTTP Client response and result of processing this response, 
> a response must be sent back to the user's original HTTP Server Request.
>   User <-> NIO Server+NIO Client <-> BackEnd
> The HTTP response from backend servers will have response entity data - 
> none of the other legs carry significant data.
> High Level Design Items:
> -----------------------
> Based on my current research into HTTPComponent NIO, it seems like I need
> following:
> 1) An NIO Server:
>   a) DefaultListeningIOReactor
>   b) DefaultServerIOEventDispatch
>   c) AsyncNHttpServiceHandler
>   d) A custom MyServerHandler - a NHttpRequestHandler implementation 
>      is registered in NHttpRequestHandlerResolver. 
>      i) This will kick off connect to NIO Client using the NIO Client Reactor. 
>      ii) NHttpRequestHandler#handle implementation retains HttpResponse and 
>        NHttpResponseTrigger into an application construct for future 
>        NHttpResponseTrigger#submitResponse when NIO Client receives response.
>        HTTPContext of NIO Client retains an id to this application construct 
>   e) Default timeout and exception processing.
> 2) An NIO Client:
>   a) DefaultConnectingIOReactor
>   b) DefaultClientIOEventDispatch
>   c) AsyncNHttpClientHandler
>   d) A custom MyClientHandler - a HttpRequestExecutionHandler  implementation
>      is registered to AsyncNHttpClientHandler.
>      i) handleResponse implementation processes the response and computes the
>        response to be sent for NIO Server Response. It retrieves the NIO server
>        saved NHttpResponseTrigger and HttpResponse and issues a submitResponse
>        for NIO Server Response to the user.
>      ii) Failure or timeout for HTTP Client triggers a failure
>        response/exception on NIO Server.
> Questions:
> ----------
> 1) Is this design idea feasible using current HTTP Component NIO implementation?

I think it is a fairly common setup for an HTTP proxy or an HTTP gateway.
Apache Synapse employs a very similar architecture.

> 2) Is it safe to retain NHttpResponseTrigger and HttpResponse for future use.

Yes, it is.

> Note that HttpResponse will be guarded for thread safety. 
> 3) Are there any constructs in the current HTTP NIO implementation that would
> facilitate the synchronization across multiple sessions like the one between NIO
> Server Session and NIO Client Session.

Not really much. There are SharedInputBuffer / SharedOutputBuffer classes that
one can use to share content between an I/O dispatch thread of an I/O reactor
and a worker thread. These classes can be used as an adaptor between NIO and
classic (blocking) I/O models.

Hope this helps


> - J.D.

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

View raw message