22.10.1 Basic Type-Specific Poller

For each interface, the IDL compiler generates a type-specific Poller value. A Poller is created by the ORB for each asynchronous invocation that uses the polling model operations. The name of the basic type-specific Poller is AMI_<ifaceName>Poller, where ifaceName is the unqualified name of the interface for which the Poller is being generated. If the interface ifaceName derives from some other IDL interface baseName, then the Poller for ifaceName is derived from AMI_<baseName>Poller, but if it does not, then it is derived from Messaging::Poller. If this name conflicts with definitions in the original IDL, additional AMI_ prefixes are prepended before <ifaceName> until a unique valuetype name is generated (such as “AMI_AMI_FooPoller? for interface Foo).

22.10.1.1 Poller operations for Interface operations

For each operation declared in the interface, a polling operation with the following signature is declared:

1. Return type void followed by

2. The name of the operation, followed by

3. A first parameter that is in unsigned long timeout indicating for how many milliseconds this call should wait until the response becomes available. If this timeout expires before a reply is available, the operation raises the system exception CORBA:TIMEOUT. Any delegated invocations used by the implementation of this polling operation are subject to the single timeout parameter, which supersedes any ORB or thread-level timeout quality of service. Two specific values are of interest:

• 0 - the call is a non-blocking poll, which raises the exception CORBA::NO_RESPONSE if the reply is not immediately available. • 232-1 - the maximum value for unsigned long indicates no timeout should be used. The poll will not return until the reply is available.

The remaining arguments, if any, are in order (all “out? parameters):

1. If the original operation has a return value, the type returned by the operation declared in IDL with parameter named ami_return_val.

2. Each inout/out type name and argument name as they were declared in IDL raises (<exceptionList>, CORBA::WrongTransaction where exceptionList contains the original operation raises exceptions, each exception from the original raises clause.

3. In addition, if the deferred synchronous model is being used:

• the poll raises the CORBA::WrongTransaction user exception (if the request has an associated transaction context), and • the polling thread either has a null transaction context or a non-null transaction context that differs from that of the request.

When a polling call is made, the operation returns in one of the following ways:

1. With the out arguments set - the reply has been returned and future queries will raise the standard exception OBJECT_NOT_EXIST.

2. By raising the reply’s exception - the reply has been returned and future queries will raise the standard exception OBJECT_NOT_EXIST. The base Poller’s is_from_poller has a value of FALSE.

3. By raising a system exception or CORBA::WrongTransaction due to a failure in the polling operation. The base Poller’s is_from_poller has a value of TRUE. Two specific exceptions are worth noting:

• CORBA::TIMEOUT - If a non-zero timeout value is specified, this system exception is raised to indicate that the specified timeout has expired and the reply has not yet been returned. • CORBA::NO_RESPONSE - If a timeout with value 0 is specified, this system exception is raised to indicate that the reply is not available.

22.10.1.2 Poller operations for Interface attributes

For each attribute declared in the interface, a polling operation with the following signature is declared. Setter polling operations are only generated for attributes that are not declared readonly: return type void followed by the name of the generated operation, which to distinguish between the getter and setter operations for an attribute is given by (respectively):

• get_<attributeName>, where attributeName is the name of the interface’s attribute, or

• 0 - the call is a non-blocking poll, which raises the exception CORBA::NO_RESPONSE if the reply is not immediately available.

• 232-1 - the maximum value for unsigned long indicates no timeout should be used. The poll will not return until the reply is available.

• set_<attributeName>, where attributeName is the name of the interface’s attribute that was not declared readonly.

A first parameter that is in unsigned long timeout indicating how many milliseconds this call should wait until the response becomes available. If this timeout expires before a reply is available, the operation raises the system exception CORBA::TIMEOUT. Any delegated invocations used by the implementation of this polling operation are subject to the single timeout parameter, which supersedes any ORB or thread-level timeout quality of service. Two specific values are of interest:

For the getter operation only

An additional argument out <attrType> ami_return_val where attrType is the type of the attribute.

The set operation takes no additional arguments.

Raises (CORBA::WrongTransaction) - If the deferred synchronous model is being used, the poll raises the CORBA::WrongTransaction user exception if the request has an associated transaction context, and the polling thread either has a null transaction context or a non-null transaction context that differs from that of the request.

When a polling call is made, the operation returns in one of the following ways:

• With the out arguments set - the reply has been returned and future queries will raise the standard exception OBJECT_NOT_EXIST.

• By raising the reply’s exception - the reply has been returned and future queries will raise the standard exception OBJECT_NOT_EXIST. The base Poller’s is_from_poller has a value of FALSE.

• By raising a system exception or CORBA::WrongTransaction due to a failure in the polling operation. The base Poller’s is_from_poller has a value of TRUE. Two specific exceptions are worth noting: