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? 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. 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.

thanks
asankha





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to