Hi Alek, The value of the non-blocking approach here is not to support longer asynchrony on the client side but rather simply more clients being mediated thru Synapse.
Without this the # of messages that synapse can mediate simultaneously is bound by the number of threads it can spawn. Clearly not acceptable. Sanjiva. On Tue, 2007-02-13 at 21:42 +0000, Paul Fremantle wrote: > Alek > > I agree that the blocking socket doesn't work as reliably as WS-A. > However, many clients still only support basic SOAP which is why we > added the Non-Blocking approach to Synapse. > > Paul > > On 2/13/07, Aleksander Slominski <[EMAIL PROTECTED]> wrote: > > Paul Fremantle wrote: > > > Michele > > > > > > We (the Synapse team) have written a pure non-blocking HTTP transport > > > for Axis2. Its currently in the Synapse repository, but we will check > > > it into the core Axis2 SVN when its stable. > > > > > > However, I wanted to clear up the asynchronous model. This isn't a > > > clear area by any means! > > > > > > The current Axis2 with Addressing is actually already asynchronous. > > > What happens is that if the replyTo address is a real HTTP URL > > > (useSeparateListener), then the client will start up a mini HTTP > > > server. The service will respond instantly with an HTTP 202 OK > > > (accepted message but not yet processed), and the HTTP connection will > > > be closed. When the response is ready, the server will open a new > > > connection to the client's HTTP server and pass the response over > > > that. > > > > > > The reason we wrote the non-blocking transport is that we wanted to be > > > asynchronous even in the case where WS-Addressing ISN'T being used. In > > > other words, the client has an open socket to the server, but we > > > didn't want to block a thread waiting for the socket. > > hi Paul, > > > > but that puts very high burden on server and TCP stack (assuming that > > you modified kernel to allow more than usual 1000 socket per process) > > and it is not robust in case when client needs to wait for response > > longer than few minutes (i have example applications that use WSA to > > wait for response for hours or days). > > > > so what is the advantage of not using WSA? > > > > > > > > > > We looked at both Mina and AsyncWeb but AsyncWeb doesn't support a > > > client model, so we based our code on the Jakarta HTTPCore project > > > which also has NIO support. > > > > > > BTW Another truly asynchronous protocol we support is SMTP. > > SMTP is exactly like WSA+SOAP+HTTP with non-anonymous ReplyTo - and as > > history shows that seems to work very well ... > > > > thanks, > > > > alek > > > > > > Paul > > > > > > On 2/13/07, Michele Mazzucco <[EMAIL PROTECTED]> wrote: > > >> Hi all, > > >> > > >> the addressing module allows for asynchronous messaging. However the > > >> used transport mechanisms are synchronous (at least tcp and http). Since > > >> alternatives exist (e.g. [1, 2]), is there any future plan to take > > >> advantage of fully asynchronous computation? > > >> > > >> > > >> Thanks, > > >> Michele > > >> > > >> > > >> [1] http://mina.apache.org/index.html > > >> [2] http://docs.safehaus.org/display/ASYNCWEB/Home > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > > > > > > > > -- > > The best way to predict the future is to invent it - Alan Kay > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- Sanjiva Weerawarana, Ph.D. Founder & Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ Director; Open Source Initiative; http://www.opensource.org/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
