TAO's Asynchronous Method Handling (AMH) Feature
Point of contact: Carlos O'Ryan,
Mayur Deshpande
Last Updated: 2002/07/29 18:14:13
The purpose of this document is to provide a guide to using the AMH
capability available in TAO. This capability is not specified by any
CORBA specification (as of date). This document lists the motivation for AMH,
how to use it and its current implementation status.
Context
For many types of distributed systems, the CORBA asynchronous method
invocation
(AMI)
mechanism can improve concurrency, scalability, and
responsiveness significantly. AMI allows clients to invoke multiple
two-way requests without waiting for responses. The time normally
spent waiting for replies can therefore be used to perform other
useful work. The TAO asynchronous method handling (AMH) is a
mechanism, which extends the concepts of AMI from clients to
servers. Servers with AMH capability can return immediately
from (potentially) long, blocking requests. This makes the
servers capable of higher throughput. For a detailed description
for the motivation and potential use-cases of AMH, please refer to
AMH-Motivation.
Using AMH
Servers that want to take advantage of AMH capability must use
AMH-servants derived from AMH-skeletons. Invoking the
IDL-Compiler
with the "-GH" option causes the IDL-Compiler to generate
AMH-skeletons for all interfaces in the ".idl" file. The signatures
of the AMH-methods differ from the original interfaces as per the
rules described in
AMH-In-Detail.
Servants derived from the AMH-skeletons are registered with the POA in the usual manner
and appear to clients as "normal" servants for the corresponding
interfaces; Thus even while being transparent to the client, these
servants are now capable of handling requests asynchronously.
AMH-servants can be registered in any POA and can intermix with
"normal" servants in the same POA. The granularity of AMH is at
the interface level and not at the method level; Thus for an interface
compiled with the "-GH" option, all operations in that interface are
asynchronous. Currently, AMH doesn't work in conjunction with
Interceptors
and behaviour is undefined if both are used together.
Current Status
(As of March 3rd, 2002)
Completed:
- Changes to ORB for asynchronous upcalls.
- Generation of AMH-skeletons.
- Generation of AMH ResponseHandlers.
- AMH Exceptions.
- Fix the narrow method bug for AMH skeletons : Fixed
- Sending intelligent exception codes back to client in case
something nasty happens in the AMH server.
- Example of using AMH available at ACE_wrappers/TAO/examples/AMH/Sink_Server.
- Test for AMH : ACE_wrappers/TAO/performance-tests/Latency/AMH
- Test for AMH Exceptions : ACE_wrappers/TAO/tests/AMH_Exceptions
Credits
Original idea first proposed by
Carlos O'Ryan
and changes to ORB for AMH first attempted by
Bruce Trask.
First go to get the IDL-Compiler to generate AMH code attempted by
Darrell Brunsch.
ORB changes for AMH as they stand today put in by
Mayur Deshpande.
Second go at getting IDL-compiler to generate code attempted by Mayur and
Jeff Parsons.
Getting the IDL-Compiler beast to generate the right AMH code finally
achieved by Carlos.