| Previous | Table of Contents | Next |
21.3.6.1 send_request
This interception point allows an Interceptor to query request information and modify the service context before the request
is sent to the server.
This interception point may raise a system exception. If it does, no other Interceptors’ send_request operations are called.
Those Interceptors on the Flow Stack are popped and their receive_exception interception points are called.
This interception point may also raise a ForwardRequest exception (see
Section 21.3.15, “ForwardRequest Exception,? on page 21-33 for details of this
exception). If an Interceptor raises this exception, no other Interceptors’ send_request operations are called. Those Interceptors
on the Flow Stack are popped and their receive_other interception points are called.
Compliant Interceptors shall properly follow completion_status semantics if they raise a system exception from this interception
point. The completion_status shall be COMPLETED_NO.
21.3.6.2 send_poll
This interception point allows an Interceptor to query information during a Time-Independent Invocation (TII) polling get
reply sequence.
With TII, an application may poll for a response to a request sent previously by the polling client or some other client.
This poll is reported to Interceptors through the send_poll interception point and the response is returned through the receive_reply
or receive_exception interception points. If the response is not available before the poll time-out expires, the system exception
TIMEOUT is raised and receive_exception is called with this exception.
This interception point may raise a system exception. If it does, no other Interceptors’ send_poll operations are called.
Those Interceptors on the Flow Stack are popped and their receive_exception interception points are called.
Compliant Interceptors shall properly follow completion_status semantics if they raise a system exception from this interception
point. The completion_status shall be COMPLETED_NO.
21.3.6.3 receive_reply
This interception point allows an Interceptor to query the information on a reply after it is returned from the server and
before control is returned to the client.
This interception point may raise a system exception. If it does, no other Interceptors’ receive_reply operations are called.
The remaining Interceptors in the Flow Stack shall have their receive_exception interception point called.
Compliant Interceptors shall properly follow completion_status semantics if they raise a system exception from this interception
point. The completion_status shall be COMPLETED_YES.
21.3.6.4 receive_exception
When an exception occurs, this interception point is called. It allows an Interceptor to query the exception’s information
before it is raised to the client.
This interception point may raise a system exception. This has the effect of changing the exception, which successive Interceptors
popped from the Flow Stack receive on their calls to receive_exception. The exception raised to the client will be the last
exception raised by an Interceptor, or the original exception if no Interceptor changes the exception.
This interception point may also raise a ForwardRequest exception (see
Section 21.3.15, “ForwardRequest Exception,? on page 21-33 for details on this
exception). If an Interceptor raises this exception, no other Interceptors’ receive_exception operations are called. The remaining
Interceptors in the Flow Stack are popped and have their receive_other interception point called.
If the completion_status of the exception is not COMPLETED_NO, then it is inappropriate for this interception point to raise
a ForwardRequest exception. The request’s at-most-once semantics would be lost.
Compliant Interceptors shall properly follow completion_status semantics if they raise a system exception from this interception
point. If the original exception is a system exception, the completion_status of the new exception shall be the same as on
the original. If the original exception is a user exception, then the completion_status of the new exception shall be COMPLETED_YES.
Under some conditions, depending on what policies are in effect, an exception (such as COMM_FAILURE) may result in a retry
of the request. While this retry is a new request with respect to Interceptors, there is one point of correlation between
the original request and the retry: because control has not returned to the client, the PortableInterceptor::Current for both
the original request and the retrying request
is the same (see Section 21.4, “Portable Interceptor Current,? on page 21-33).
21.3.6.5 receive_other
This interception point allows an Interceptor to query the information available when a request results in something other
than a normal reply or an exception. For example, a request could result in a retry (for example, a GIOP Reply with a LOCATION_FORWARD
status was received); or on asynchronous calls, the reply does not immediately follow the request, but control shall return
to the client and an ending interception point shall be called.
For retries, depending on the policies in effect, a new request may or may not follow when a retry has been indicated. If
a new request does follow, while this request is a new request with respect to Interceptors, there is one point of correlation
between the original request and the retry. Because control has not returned to the client, the request scoped PortableInterceptor::Current
for both the original request and the retrying
request is the same (see Section 21.4, “Portable Interceptor Current,? on page 21-33).
This interception point may raise a system exception. If it does, no other Interceptors’ receive_other operations are called.
The remaining Interceptors in the Flow Stack are popped and have their receive_exception interception point called.
This interception point may also raise a ForwardRequest exception (see
Section 21.3.15, “ForwardRequest Exception,? on page 21-33 for details on this
exception). If an Interceptor raises this exception, successive Interceptors’ receive_other operations are called with the
new information provided by the ForwardRequest exception.
Compliant Interceptors shall properly follow completion_status semantics if they raise a system exception from this interception
point. The completion_status shall be COMPLETED_NO. If the target invocation had completed, this interception point would
not be called.