Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — Open Issues

  • Acronym: CORBA
  • Issues Count: 1
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA35-168 ForwardRequest is impossible to detect in clients CORBA 2.6.1 open

Issues Descriptions

ForwardRequest is impossible to detect in clients

  • Legacy Issue Number: 5266
  • Status: open  
  • Source: Oracle ( Andrew Piper)
  • Summary:


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


    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.


    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:

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


    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, 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.


    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.


    • Change the IDL in 21.3.12 to include
      void set_slot (in SlotId id, in any data) raises (InvalidSlot);
    • After move in the text from
    • Change the IDL in 21.3.14 to remove set_slot()
  • Reported: CORBA 2.6.1 — Thu, 2 May 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT