synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera" <>
Subject Re: A basic non-blocking http/s implementation for Axis2/Synapse
Date Wed, 11 Oct 2006 05:03:08 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
Hi Oleg<br>
I was looking at the example <a
in the NIO extensions and am looking at the following two fragments of
<pre>   static class DefaultIoEventDispatch implements IOEventDispatch {
   public void connected(IOSession session) {
            httpService.registerRequestHandler("*", new HttpFileHandler());
public interface HttpRequestHandler {<br>
&nbsp;&nbsp;&nbsp; void handle(HttpRequest request, HttpResponse response, HttpContext
context) <br>
throws HttpException, IOException;<br>
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.<br>
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.<br>
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.<br>

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message