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]
