axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <stev...@iseran.com>
Subject Re: Asynchronous Transport in Apache Axis, JMS and beyond
Date Thu, 05 Sep 2002 16:47:09 GMT

----- Original Message -----
From: "Aleksander Slominski" <aslom@cs.indiana.edu>
To: <axis-dev@xml.apache.org>
Sent: Thursday, September 05, 2002 8:35 AM
Subject: Re: Asynchronous Transport in Apache Axis, JMS and beyond



> i think that callbacks have serious scalability limitations - what if AXIS
has
> to handle thousands of async responses simultaneously?
> there may be not enough threads available to deliver callbacks,
> you could queue callbacks delivery and pool threads but it will also
> impact perfromance...
>
> i think that providing alternative synchronization constructs that may be
more
> efficient would be very good . for example to notify user code about
status of asynchronous
> response it may be better to use something similar to select() in UNIX  -
> this is tested and proven solution to handling multiple socket connections
in many web servers...

Yes, and java.nio finally gives the world select() in 1.4. Without that you
still need to block per thread on every open socket, so if the async xport
uses open sockets, you are limited to nthreads. And even nio, as,
implemented, is duff on win32 because they chose to implement the waiting
using WaitForMultipleObjects(), whch is limited to 64 objects -if they'd
used IoCompletionPorts then on nt there would be no real limits to scaling.

For async stuff if you can have multiple objects waiting and a pool of
threads to service them then all is well on java1.2+, which is why it is
such a common design pattern.


Mime
View raw message