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()

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

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()

It is used by RealTime CORBA as documented in 24.17.2

non issue...editorial, issue withdrawn

suppose the following [pseudo-]idl:

#pragma prefix "2abc.def"

module xyz {
interface q

;
};

It would generate a Java class 'q' within package 'def.2abc.xyz'.
The package name '2abc' is not that popular with the java compiler
since it starts with a digit.

From what I could see in CORBA 2.6.1, identifiers have to start
with a character (or at least not a digit). So, I guess that the
prefix pragma is erroneous here, right ?

The OpenORB IDL parser 1.2.0 did though generate Java code without any
complaints, which confuses me ...

see above

Could we please discuss the possibility of introducing a performance
optimization for Interceptors.

There may be considerable overhead involved in invoking Portable
Interceptors. While some interceptors need to be invoked when caller
and target are colocated (the locally optimized path), many do not.
I think it would be useful to introduce a mechanism to allow this
unnecessary overhead to be avoided for interceptors that do not need
to be invoked on the colocated path, for example by adding a
'run_local' parameter to the add_xxx_request_interceptor methods of
the ORBInitInfo interface.

I realise that this issue was touched upon during discussion of interop
issue 4291 but, at the time, the focus was on getting the interceptor
mechanism to work correctly in the colocated case; the performance
aspect of the issue seems to have been lost.

Provide means for the optimization as shown below

1. There's no minor code assigned to the use of CODESET_INCOMPATIBLE
for a failed codeset negotiation in 13.10.2.6.

2. There's no indication of what a server should do if the client
delivers a codeset via a CodeSetContext that the server does not support
as a transmission codeset). This isn't likely to happen, but we ought
to close the hole. I propose that we have the server raise
CODESET_INCOMPATIBLE (with a different minor code from 1) in this case
too.

3. Would it be a good idea for us to include recommendations on how to
change a persistent server's native codeset while remaining backwards
compatible with existing IORs floating around the world with obsolete
CodeSetComponent data? Or is it too obvious? (Just make sure the new
server advertises (or at least continues to support) the old native
codeset as a transmission codeset.)

see above

The minor codes in the specified NO_IMPLEMENT exceptions are incomplete/inconsistent.

In particular:

1) In 3.7.6.1 "Semantics", minor code 3 is mentioned for DII support pseudo-operations, but 3.7.6.2 seems to specify minor code 4 for these (though it uses different wording).

2) 3.7.6.2 "LocalObject" doesn't specify the minor code for "is_a" etc, though presumably it should be 3 as in 3.7.6.2.

3) The explanation for minor code 3 is "Unable to use any profile in IOR." but that isn't particular clear for local objects, which probably don't have an IOR at all.

see above