|
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.. 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. 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 |
- non blocking http - initial checkin Asankha C. Perera
- Re: non blocking http - initial checkin Aleksander Slominski
- Re: non blocking http - initial checkin Asankha C. Perera

