synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <>
Subject Re: HTTP NIO
Date Tue, 10 Oct 2006 18:52:36 GMT
Paul Fremantle wrote:
> Oleg
> Firstly, I'm copying synapse-dev!
> I'm not an expert so please forgive me if I make basic mistakes in
> understanding this.
> I agree our main requirement is simply to disconnect the thread model
> from the socket model. But since Axis2 can partially parse messages, I
> can see how we could start processing the SOAP headers before the
> whole of a large message was received. Especially if there is a
> monster file attachment. In other words, I would like to be able to
> start streaming an attachment out to the server before I've finished
> reading it from the client.

Hi Paul,

I see absolutely nothing that prevents you from doing that even using 
blocking I/O. With the existing JVMs that are widely used in production 
(Sun 1.4, Sun 1.5 for instance) these days classic I/O tends to be 
significantly faster compared to NIO. This situation may change sometime 
in the future, but for a number of years to come that's just the way 
things are. One should not assume NIO necessarily provides performance 
benefits compared to classic I/O only because Sun called it New IO. NIO 
can certainly buy you more design flexibility (especially when it comes 
to dealing with threads) but at a significant price in terms of 
increased complexity, reduced performance and larger memory footprint. 
NIO should be used with caution where appropriate.



> Is that the kind of thing you are talking about?
> Paul
> On 10/10/06, Oleg Kalnichevski <> wrote:
>> I would like to get a new release of HttpComponents Core (including NIO
>> extensions) by the end of the month the latest. So, I am preparing for a
>> major push in the coming days. I do not know if that's too late for
>> Synapse or not.
>> I have spoken to Asankha on several occasions and what is still unclear
>> to me whether Synapse _really_ needs an event driven HTTP transport and
>> if so what is the reason for such requirement. As far as I know (and
>> admittedly I know little about Axis / Synapse) the process of generating
>> SOAP entities is inherently blocking because of its reliance on the
>> InputStream / OutputStream API. If Synapse needs a worker thread to
>> handle SOAP payload anyways, what's the point of wanting an event driven
>> HTTP transport? I feel that an HTTP transport that does not require a
>> thread per connection and can efficiently handle thousands of concurrent
>> connections with a reasonable pool of worker threads (~50) should be a
>> much more appropriate architecture for Synapse.
>> Cheers
>> Oleg

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

View raw message