On Tue, May 27, 2008 at 3:29 PM, Andreas Veithen <[EMAIL PROTECTED]> wrote:
> > On 27 May 2008, at 20:27, Asankha C. Perera wrote: > > Hi Bob >> >>> We are currently investigating options for migrating our existing >>> software solution towards an ESB, with a particular emphasis on >>> asynchronous IO. >>> >>> Our system is essentially a switching router, accepting requests over >>> HTTP(S), and routing them to an appropriate service-provider. >>> Communication to these third-party providers is via TCP socket >>> request/response. >>> >>> We are looking to maximise concurrency; by far the bulk of our >>> round-trip time is currently spent waiting for responses from these >>> 3rd parties, so we are keen to replace our current process-per-child >>> model with one based on an asynchronous core, and Synapse is one of >>> the frameworks being considered. >>> >>> Synapse already has a non blocking http/s implementation using Apache >> HttpComponents-HttpCore/NIO, which gives it great performance. >> >>> However, my initial investigations suggests that there is not >>> currently a plain old TCP socket transport available. Can somebody >>> please confirm/deny this? >>> >>> There was an initial raw TCP transport available with Apache Axis2, but >> I have seen Andreas committing a better TCP/UDP implementation using NIO >> being checked into the Synapse trunk in the last few weeks. Thus, the >> combination of these two non-blocking transports will get you what you are >> looking for.. >> >> > This is more credit than I deserve :-) > > Actually I added two new transports: one for UDP and one to read from a > UNIX pipe (aka named pipe, aka FIFO). The UDP transport indeed uses a non > blocking approach, but it is a datagram transport in the sense that it reads > the entire message into memory before starting to process it. The pipe > transport uses file I/O and is blocking (there is no non blocking file I/O > in Java). For various reasons it is actually also built as a datagram > transport, i.e. it doesn't support streaming. Currently the only TCP > transport implementation is the one from Axis2. Neither the UDP and nor the > pipe transport implementation is useful as a starting point to build a TCP > transport. Indeed, a good TCP transport should be non blocking and support > streaming. Implementing this is a non trivial task as we learned from the > problems with the HTTP transport (SYNAPSE-321). > > Andreas > > Writing such a transport is indeed a non trivial excercise. There are frameworks such as MINA, Grizzly for nio. For Apache Qpid we used MINA but we are reevaluating it. I did quite a bit of perf testing on the client side with MINA and see that memory is definitely an issue. Balancing throughput vs latency was difficult. I finally wrote a blocking transport on the client side (using java.io ) that gave much much better latency, throughput and memory. However this model is only good where you can devote a thread per connection. For a client this usually is the case, but not for a server in general. Even for a server a blocking transport may not be an issue if the number of connections are low and you have enough CPU. In such a case the overhead of context switching (if any) will be less than the overhead of select/poll or epoll system calls you get with non blocking io multiplexing with java.nio. However for a server with a large no of connections non blocking is the way to go. There is also something called async io written by Tim (Apache Harmony) and Mike (SCA). I think it didnt' go much further, but they had some interesting points in some articles. From the looks of it they even had asynchronous write operations and completion was notified via a callback. This was written after nio came in to place and I wonder why they abandoned the project http://www.alphaworks.ibm.com/tech/aio4j Anyways I am keen on this area as Qpid can benefit from what you guys discover (and vice versa). Andreas I am looking forward to the work you are doing in this space. Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/
