| Previous | Table of Contents | Next |
A ClientRequestInterceptor instance is registered with the ORB. The ORB logically maintains an ordered list of client-side
Interceptors. The Interceptor list is traversed in order on the sending interception points and in reverse order on the receiving
interception points.
21.3.7.1 Client-side Flow Rules
The client-side flow rules are derived from the general flow rules (see Section 21.3.2,
“General Flow Rules,? on page 21-7):
• The set of starting interception points is: send_request and send_poll. One and only one of these is called on any given request/reply sequence.
• The set of ending interception points is: receive_reply, receive_exception, receive_other. One and only one of these is called on any given request/reply sequence.
• There are no intermediate exception points.
• If and only if send_request or send_poll runs to completion is an ending interception point called.
21.3.7.2 Additional Client-side Details
If, during request processing, a request is canceled because of an ORB shutdown, receive_exception is called with the system
exception BAD_INV_ORDER with a minor code of 4 (ORB has shutdown).
If a request is canceled for any other reason (for example, a GIOP cancel message is sent by the ORB), receive_exception is
called with the system exception TRANSIENT with a standard minor code of 2.
On oneway requests, returning control to the client may occur immediately or it may return after the target has performed
the operation, or somewhere in-between
depending on the SyncScope (see Section 21.3.12.9, “sync_scope,? on page 21-23).
Regardless of the SyncScope, if there is no exception, receive_other is called before control is returned to the client.
Asynchronous requests are simply two separate requests. The first request receives no reply. The second receives a normal
reply. So the normal (no exceptions) flow is: first request -send_request followed by receive_other; second request send_request
followed by receive_reply.
21.3.7.3 Client-side Flow Examples
Given the client-side flow rules, here are some concrete examples:
• For successful invocations: send_request is followed by receive_reply - a start point is followed by an end point.
• For retries: send_request is followed by receive_other - a start point is followed by an end point.
• For successful TII polls, send_poll is followed by receive_reply -a start point is followed by an end point.
• For TII polls whose response is unavailable, send_poll is followed by receive_exception - a start point is followed by an end point.
For the following exception scenarios, assume we have Interceptors A, B, and C. On the send interception points they are called
in the order A, B, C; on the receive interception points they are called in the order C, B, A.
Scenario
An exception arrives from the server:
• A.send_request is called;
• B.send_request is called;
• C.send_request is called;
• C.receive_exception is called;
• B.receive_exception is called;
• A.receive_exception is called.In this scenario you can see that the flow for each Interceptor follows the rules.
They are all: send_request followed by receive_exception - a start point is followed by an end point.
Scenario
B.send_request raises an exception:
• A.send_request is called;
• B.send_request is called and raises an exception
• A.receive_exception is called.
In this scenario you can see that the flow for each Interceptor follows the rules:
• The flow for A is send_request followed by receive_exception - a start point is followed by an end point.
• The flow for B is send_request -a start point did not complete, so no end point was called; B raised the exception, so there is no need to tell it that the exception occurred.
• The flow for C is non-existent since the exception occurred before any of C’s interception points was invoked - a start point was not called, so no end point is called.
Scenario
A reply returns successfully from the server, but B.receive_reply raises an exception:
• A.send_request is called;
• B.send_request is called;
• C.send_request is called;
• C.receive_reply is called;
• B.receive_reply is called and raises an exception;
• A.receive_exception is called.
In this scenario you can see that the flow for each Interceptor follows the rules:
• The flow for A is send_request followed by receive_exception - a start point is followed by an end point.
• The flow for B is send_request followed by receive_reply - a start point is followed by an end point.
• The flow for C is send_request followed by receive_reply - a start point is followed by an end point.
The scenario for B raising an exception at receive_other is similar to the scenario where B raises an exception at receive_reply.
Scenario
An exception X is returned by the server, but B.receive_exception changes the exception to Y:
• A.send_request is called;
• B.send_request is called;
• C.send_request is called;
• C.receive_exception is called with X;
• B.receive_exception is called with X, raises Y;
• A.receive_exception is called with Y.
In this scenario, the flow for all Interceptors is send_request followed by receive_exception - a start point followed by
an end point - Interceptor A is handed exception Y while the B and C are handed exception X.