axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Chappell <chapp...@sonicsoftware.com>
Subject Re: Asynchronous Transport in Apache Axis, JMS and beyond
Date Thu, 05 Sep 2002 16:11:20 GMT
See below - 

Aleksander Slominski wrote:
> 
> James M Snell wrote:
> 
> > Alek, Thanks for your feedback.  Comments in line below.
> 
> hi,
> 
> i think that aync messaging/invocations are crucial for web services
> so it is nice to see that AXIS may have it working. especially interesting
> would be too see one-way messaging implemented over HTTP ...
> 
> more comments below.
> 
> > Aleksander Slominski <aslom@cs.indiana.edu> wrote on 09/04/2002 04:02:48 PM:
> > > James M Snell wrote:
> > > 17            while (call.getAsyncStatus() != Call.ASYNC_READY) {}
> > > one thing that caught my eye: do you recommend as standard
> > > approach to use busy wait?! i think that much better approach is
> > > to have both status checking and blocking call to request
> > > async operation to finish in given timeout in ms, for example
> > >
> > >     boolean gotResult = call.waitForResult(10 * 000);
> >
> > Either approach will work but your suggestion is more user friendly.  I think that
implementing both
> > approaches is a good idea.
> >
> > There is another option, btw, that allows the user to specify a callback listener
implemention.  This
> > will allow the user to receive response and fault events directly.  I did not include
this in my
> > initial discussion because I am considering it more of an advanced "here's enough
rope to hang
> > yourself" option that the typical user would not use.  It will be documented when
the prototype is up
> > and running.
> 
> 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?

> 
> 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?

> 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 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.
Dave

> 
> > > Line 17 illustrates how the user can check to see when a response
> > > has been received.  While the async operation is processing, call.
> > > getAsyncStatus() will return Call.ASYNC_RUNNING.  When the operation
> > > completes, the value will switch to Call.ASYNC_READY.  The client
> > > can then call.getReturnValue() to return the response value.one
> > > possible result of operation may be exception i.e. result is
> > > containing SOAP:Fault
> > > how would it be handled by Call object? i think you will need to
> > > wrap exception
> >
> > There will be a method on the call object (getReturnedFault) that will allow the
user to access fault
> > information.  When the status returns to ASYNC_READY and the return value is null,
the developer
> > should check to ensure that getReturnedFault is also null to verify that an exception
was not
> > returned.
> 
> actual return value can be null as i can easily have service that returns null
> as legal return value - right?
> 
> when "futures" are used it is possible to have more bullet proof mechanism
> that does not depend on user to check for special values. essentially
> it is an alternative getReturnValue/getReturnedFault combo that will return
> value (including null if it is actual value) or throw fault exception
> if SAOAP:Fault was received, something like this:
> 
> public Call {
>    public Object blockForReturnValue(long timeToWait) throws Throwable;
> }
> 
> thanks,
> 
> alek

-- 
Sonic Software - Backbone of the Extended Enterprise
--
David Chappell <chappell@sonicsoftware.com> Office: (781)999-7099
Mobile: (617)510-6566
Vice President and Chief Technology Evangelist, Sonic Software
co-author,"Java Web Services", (O'Reilly 2002)
"The Java Message Service", (O'Reilly 2000)
"Professional ebXML Foundations", (Wrox 2001)
--

Mime
View raw message