On Wed, 2006-10-11 at 10:33 +0530, Asankha C. Perera wrote:
> Hi Oleg
>
> I was looking at the example AsyncHttpServer in the NIO extensions and
> am looking at the following two fragments of code...
>
> static class DefaultIoEventDispatch implements IOEventDispatch {
> ....
> public void connected(IOSession session) {
> ...
> httpService.registerRequestHandler("*", new HttpFileHandler());
> ...
> worker.start();
> ...
> }
> ...
> -------------------------
>
> public interface HttpRequestHandler {
>
> void handle(HttpRequest request, HttpResponse response,
> HttpContext context)
> throws HttpException, IOException;
> }
>
>
> Does the above imply that we always need to create a new thread to
> handle each new connection?
Hi Asankha,
Yes, it does. This is, however, a temporary hack that enabled me to test
NIO based I/O reactor using proven code from HttpCore proper. I am still
working on the asynchronous HTTP protocol handler, but I prefer
developing and testing code in short iterations.
> Also, when Synapse receives a message it may not know how to reply to
> it immediately - unlike a web server, as the response may depend on
> the response received from another web service to which the request
> needs to be forwarded. Hence at the implementation of the
> HttpRequestHandler interface's handle() method we have a problem.
>
> AsyncWeb exposes a HttpService.handleRequest(HttpRequest request)
> method, where it is easier for us to handle just the received request.
> Once we are ready to respond, we could use request.createResponse()
> and perform a HttpResponse.commit(). So the processing of the request
> and the response could take place over two distinct threads [of the
> common worker thread pool]. They state that any methods invoked on the
> streams returned by HttpRequest#getInputStream() and
> HttpResponse#getOutputStream() will never block - and I guess this
> implies that they have buffered the complete request in memory.
Well, would you want to run a web service in production that can die on
you with 'out of memory' exception under load? I would not. This is way
worse that refusing connections under load due to the worker thread
depletion because it leaves the client without a reliable recovery
strategy. In my humble opinion AsyncWeb has severe architectural issues
due to its memory management.
> As Synapse runs on top of Axis2, we may not need to 'parse' the
> complete XML messages for us to do play our role (say CBR), but I
> think we should process them only after they have been fully read.. as
> we may need to forward them to another service etc. according to the
> configured rules we use.
>
> As AsyncWeb does not [yet] provide a stable client, we started to try
> and develop our own transport, which is essentially a subset of a
> standard http implementation - but which is very similar to your NIO
> extensions - with the distinction mentioned above, which was borrowed
> from AsyncWeb.
>
Do you have any interest in contributing some that code to
HttpComponents?
Cheers
Oleg
> thanks
> asankha
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For
> additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
