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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
