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

Since there doesn't appear to be a CosNaming mailing list this seems like as good a forum as any this discussion.

It has long struck me that the use of CosNaming for JNDI in J2EE applications creates a significant outage in being able to bind and retrieve objects that are not remote (see the EJB 2.0 spec for details). In JNDI you can bind pretty much anything that is Remote (aka an Object reference) or Serializable (aka a valuetype), however CosNaming only allows you to do the former.

One easy way to solve this would be to create a new NamingContext extension that allows one to bind and resolve Any's. This is in keeping with the Java-to-IDL spec's treatment of untyped Java objects and at the same time would not compromise non-java implementations. For JNDI it would only be necessary to support Any's containing:

1. Object references
2. valuetypes
3. valueboxes

An exception could be thrown for any other types. The candidate interface might look something like this:

module CosNaming {
interface NamingContextAny : NamingContextExt {
exception TypeNotSupported {};

void bind_any(in Name n, in any obj)
raises (NotFound, CannotProceed,
InvalidName, AlreadyBound, TypeNotSupported);

void rebind_any(in Name n, in any obj)
raises(NotFound, CannotProceed, InvalidName, TypeNotSupported);

any resolve_any (in Name n)
raises (NotFound, CannotProceed, InvalidName);

any resolve_str_any(in StringName n)
raises (NotFound, CannotProceed,
InvalidName, AlreadyBound);
};
};

The implementation of this interface in Java is trivial, although perhaps less so in other languages. Whether or not that matters is open to question.

The Portable Object Adapter and Portable Interceptors both are able to
raise a ForwardRequest exception to allow redirection to another
object.

What happens if the ForwardRequest is to a local object?

Is this even possible?

Should it be allowed?

I suggest we change the specification to make this illegal.