Re: non blocking http - initial checkin

[Aleksander Slominski <as...@cs.indiana.edu>]

Asankha C. Perera wrote:
>
> I have checked in the initial cut of the non-blocking http transport
> as promised.. however, note that this is still under development and
> needs cleanup, refactoring, and some more features and testing to be
> called complete or stable. However, the idea is to show how this is
> going to be of use to Synapse..and to get initial feedback.

>
> The o.a.axis2.transport.niohttp.impl package contains the core (Axis2
> independent) http transport, with a sample ReactorTester
> <http://svn.apache.org/viewvc/incubator/synapse/trunk/java/modules/niohttp/src/org/apache/axis2/transport/niohttp/impl/ReactorTester.java?view=markup>..
> this could be run without the need of Axis2/Synapse etc. This shows
> how the (currently single threaded) Reactor hands over a received
> request to be processed. In the case of Synapse, this processing will
> take place on one of the Synapse threads from a pool. As an example,
> consider the case where Synapse sends this off to an actual service
> EPR. Once the response is received asynchronously, again a new thread
> from the pool will process this response. The example shows how the
> response could be tied back to the original request, so that it could
> now be forwarded to the client again by attaching to the original socket.
>
>
> The above picture shows the separation of IO threads from those used
> by Synapse for processing received messages (i.e. mediation). In
> essence, the Synapse threads would never block for IO, and hence if
> the pool ever gets exhausted, thats because Synapse is actually
> performing message mediation and not blocking on IO. This would allow
> Synapse to deal with many clients and backends, using a small pool of
> threads. 
for the last part (two threads for NIO Sender) how will synapse deal
with the situation when socket timed out and there is no way to send
response (this would be pretty common if it takes longer than few
minutes to finish synapse processing/mediation, especially if synapse
invoked external service as part of execution and the invoked service
takes longer than socket timeout set by client to finish ...)

should it try to detect timeout and send fault to client?

best,

alek
>
> The code generally follows the Reactor pattern described at
> gee.cs.oswego.edu/dl/cpjslides/nio.pdf
>
> The next steps I will be working on are:
>     Finish implementation of a basic Axis2 http transport over this
>     Implement socket timeouts, and support 100 continue and 202 processing
>     Integration of the Axis2 transport with Synapse - including
> testing with WS-RM etc
>     Implement SSL support - (client side first)
>
> Some more steps are documented on the Reactor.java class, but would be
> done according to priority and time.
>
> Your feedback, comments and suggestions for improvement are welcome
> asankha


-- 
The best way to predict the future is to invent it - Alan Kay


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

Re: non blocking http - initial checkin

["Asankha C. Perera" <as...@wso2.com>]

Hi Alek

> for the last part (two threads for NIO Sender) how will synapse deal
> with the situation when socket timed out and there is no way to send
> response (this would be pretty common if it takes longer than few
> minutes to finish synapse processing/mediation, especially if synapse
> invoked external service as part of execution and the invoked service
> takes longer than socket timeout set by client to finish ...)
>
> should it try to detect timeout and send fault to client?  
Yes, we can have timeouts as well as detect socket close by the remote 
client. If the client supplies a reply to or a fault to address, I think 
then we could handle this case neatly

asankha

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