synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: HTTP NIO
Date Tue, 10 Oct 2006 19:38:00 GMT
Paul Fremantle wrote:
> Oleg
> 
> Ok so now I'm really lost!
> 
> So how do you disconnect the thread from the socket with the standard
> HTTPClient?
> 
> Paul
> 

Commons HttpClient does that as of version 2.0-alpha2 if my memory does 
not fail me. HttpClient can optionally maintain a very large pool of 
connections, which a much smaller number of worker thread can borrow 
connections from. This model, however, is still sub-optimal for some 
scenarios where worker threads can stay blocked for too long waiting for 
the response to arrive. HttpCore (that's what HttpClient 4.0 will be 
based on) no longer has this limitation.

Oleg

> On 10/10/06, Oleg Kalnichevski <olegk@apache.org> wrote:
>> 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.
>>
>> Cheers,
>>
>> Oleg
>>
>> > Is that the kind of thing you are talking about?
>> >
>> > Paul
>> >
>> > On 10/10/06, Oleg Kalnichevski <olegk@apache.org> 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: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org


Mime
View raw message