axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject Re: Asynchronous Transport in Apache Axis, JMS and beyond
Date Thu, 05 Sep 2002 16:54:33 GMT
David Chappell wrote:

> See below -
> Aleksander Slominski wrote:
> >
> > James M Snell wrote:
> > there are some problems with callbacks including implementation overhead.
> > as there is no guarantee on how fast user provided callback function must return
> > (it can also get stuck and may not be able to return ever!) so you need to have
> > defensive approach typically having each callback delivered in a separate thread.
> The getting stuck and returning never situation is covered by your
> timeout option suggestion on the waitForResult() method, right?

yes - by exception similarly to Object.wait()

> >
> > i think that callbacks have serious scalability limitations - what if AXIS has
> > to handle thousands of async responses simultaneously?
> What does AXIS do to handle this on the service side?  Is this a new
> issue that is unique to callbacks?

this is the same problem. i do not think it was solved or there is a generic solution
that works for all situations.

> > there may be not enough threads available to deliver callbacks,
> > you could queue callbacks delivery and pool threads but it will also
> > impact perfromance...
> Serializing callbacks and pooling threads can positively impact
> performance, in my experience.  The throttling effect created by pooling
> and serialized notification is far less of an impact than the thread
> context thrashing that can occur when threads are spawned
> uncontrollably.

i am just a bit concerned about serializing callback notifications.
it is difficult in Java to deal with situation when user code in callback
never returns.

> > 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...
> I'm no expert on select(), but my recollection of select() is that you
> pass it an array of known sockets that you are listening on, then walk
> through it and check for activity on each FD whenever something
> arrives.


>  Are you suggesting something like that? Do we have a
> comparable situation here?  Even in the select() case, you may have
> multiple "send" operations arriving from the remote party occuring on an
> individual socket, yet the data is buffered in a layer that is not
> visible to the application code.  So in effect, there is some kind of
> 'queueing' that is implicitly happening there.

well there will be service endpoint(s) that will receive all those
asynch response messages and then will need to pass it to interested
parties. of course if you assume that processing async response message should
be blocking then there is no problem - you can use the thread that was spawned
by endpoint to handle request to use it to process user code in callback.
that assumes that each message processing can be finished in reasonable time
and it works best if there is no state shared between callbacks
(if there is non trivial state shared then code quickly will become ugly...)

however in case that there is longer running process that just have to receive
signals (events) then situation looks differently. in this case you want use callback
to actually just deliver signal that message arrived and have processing done
in separate part of application and i think you would expect callback to return quickly ...

so essentially there are two use cases of callbacks that will heavily affect
possible design choices
1) callbacks to do actual processing that blocks until task is finished
2) callbacks that are used just to deliver signal

i think that case 2) is much more common than 1)
but i am eager to hear other opinions.

as of implementation choices for implementing callbacks:
if you use callback then you register your interest in one message
and you will need to register a callback for each response message
you want to process. delivery can be done in thread that is processing
requests on endpoint (blocking it) or it can be handled by separate thread(s).
if any of callbacks will misbehave (or just block for longer time than expected
on average) the performance of system may quickly degrade as there
will be many threads that are not yet finished ...

using select() like mechanism each piece of user code can register interest
in thousands of async response messages and there is no need for creating any
threads to deliver async response message to user code. this is possible
as async response message can be put into select() maintained storage
and keep it there until user will call select() to pick up newly arrived
messages for processing when it is ready to do it and that makes writing code
to deal with async messages in case 2) much much easier ...

just my .02c



View raw message