CORBA35 — ForwardRequest is impossible to detect in clients

REQUIREMENT

To be able to use interceptors, and in particular ForwardRequest, in a client to perform active, per-request, load-balancing.

PROBLEM

It is not possible to detect in an interceptor whether ForwardRequest has previously been thrown for the same client request. Thus it is possible for a client to go into an infinite loop throwing ForwardRequest.

DISCUSSION

The basic problem is that although for a single client request the request-scoped PICurrent is shared across across interceptor invocations - even when ForwardRequest is thrown - it is not possible to modify this information in an interceptor to indicate to a future invocation that the invocation has been seen. The two relevant parts of the spec here are:

21.3.6.5

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 Chapter 21, Portable Interceptors on page 21-32).

21.4.2

Before an invocation is made, PICurrent is obtained via a call to
ORB::resolve_initial_references ("PICurrent")
From within the interception points, the data on PICurrent that has moved from the
thread scope to the request scope is available via the get_slot operation on the
RequestInfo object. A PICurrent can still be obtained via
resolve_initial_references, but that is the Interceptor's thread scope PICurrent.
See section 21.4.4.4, Request Scope vs Thread Scope on page 21-36 for a detailed
discussion of the scope of PICurrent.

Thus modifications to the thread's PICurrent are lost on retries and modifications to the request's PICurrent are not possible.

PROPOSED RESOLUTION

I have made several different attempts at coming up with a portable way of solving this problem without changing the spec, but have failed. It seems to me that it really should be possible for the interceptor to know that a retry is in effect and I can think of a number of different solutions to this:

1. add:
void set_slot (in SlotId id, in any data) raises (InvalidSlot);
to RequestInfo. This would allow interceptors to transfer information between invokes of the same client request and thus a retry could be detected.

2. Add a new function to RequestInfo to indicate that a forward is in operation. The minimalist fix here would be to allow forward_reference() to be accessed in send_request() as well as in receive_other(). i.e. returning the object from the previous ForwardRequest if that has been thrown.

I'm ambivalent about which of these is best but for the sake of simplicity I'm going to plump for (1) because this is already allowed in ServerRequestInfo.

So:

• Change the IDL in 21.3.12 to include
  void set_slot (in SlotId id, in any data) raises (InvalidSlot);

• After 21.3.12.12 move in the text from 21.3.14.6

• Change the IDL in 21.3.14 to remove set_slot()