You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Paul Fremantle <pz...@gmail.com> on 2006/10/10 19:20:03 UTC
HTTP NIO
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.
Is that the kind of thing you are talking about?
Paul
On 10/10/06, Oleg Kalnichevski <ol...@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
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: HTTP NIO
Posted by Oleg Kalnichevski <ol...@apache.org>.
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 <ol...@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 <ol...@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
Re: HTTP NIO
Posted by Paul Fremantle <pz...@gmail.com>.
Oleg
Ok so now I'm really lost!
So how do you disconnect the thread from the socket with the standard
HTTPClient?
Paul
On 10/10/06, Oleg Kalnichevski <ol...@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 <ol...@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
> >>
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: HTTP NIO
Posted by Oleg Kalnichevski <ol...@apache.org>.
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 <ol...@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