[omniORB] LOCATION_FORWARDs, LocateRequests

[Duncan Grisby]

On Monday 22 December, baileyk at schneider.com wrote:

> 1) When omniORB4 is acting as a client, should a reference that has been
> forwarded revert to the original IOR when the new one generates a TRANSIENT
> request?  The language I see in the CORBA spec is this (section 15.6):
> 
>   A client shall not make any assumptions about the longevity of object
> addresses
>   returned by LOCATION_FORWARD (OBJECT_FORWARD) mechanisms. Once a
>   connection based on location-forwarding information is closed, a client
> can attempt to
>   reuse the forwarding information it has, but, if that fails, it shall
> restart the location
>   process using the original address specified in the initial object
> reference.

The problem with that bit of spec is that it doesn't define "fails".
Does that cover any system exception, or what?  It's talking in the
context of GIOP connections, so it only really covers the connection
failure case.

> I have a server that throws a TRANSIENT explicitly to tell the client to
> retry the request.  There is a Implementation Repository-like service that
> all the IORs the client has originate from, but the client just gives up
> right away rather than retry on the original reference.  The code in
> omniObjRef seems to support the conclusion that TRANSIENT never reverts...

You are right that TRANSIENT doesn't revert. Most people don't see
that, though, since usually the TRANSIENT exceptions you see are
connection failures, and they are handled by the code higher up that
deals with giopStream::CommFailure.

So, what currently happens is that COMM_FAILURE, OBJECT_NOT_EXIST and
TRANSIENTs caused by connection failures are the only things that
cause an object reference to revert. It's not obvious to me what the
correct behaviour should be. Certainly you sometimes want to revert,
but other times you probably don't. Do you want to revert when you get
a transaction related exception, for example?  Probably not.  How
about a TRANSIENT generated by a POA in discarding state?  Also
probably not. But a TRANSIENT generated due to a timeout?  Maybe you
do want to revert.

One solution is to not change anything in omniORB, and leave it up to
application registered exception handlers. They are free to call
omni::revertToOriginalProfile to reset an object reference.

Does anyone have any opinions?  My interpretation of the spec is that
it doesn't have anything to say about the matter.

> 2) Is there a way in omniORB to hook into the handling of LocateRequests
> and reply with an OBJECT_FORWARD?  My repository has a servant manager that
> always throws a ForwardRequest from the preinvoke() method.  As I
> understand it, when omniORB is a client it always does a LocateRequest by
> default.  I'm seeing the preinvoke called with the operation name of the
> first method invocation done by the client, so I assume the LocateRequest
> was replied to with OBJECT_HERE and no calls were done on my servant
> manager.

No, there's no way to hook the replies to LocateRequests. The POA spec
implies that the ORB might choose to call preinvoke in response to a
LocateRequest (section 11.3.6):

  If preinvoke raises an exception, postinvoke is not called.
  Otherwise the preinvoke and postinvoke operations are always called
  in pairs in response to any ORB activity. In particular, for a
  response to a GIOP Locate message a GIOPconforming ORB may (or may
  not) call preinvoke to determine whether the object could be served
  at this location. If the ORB makes such a call, whatever the result,
  the ORB does not invoke a method, but does call postinvoke before
  responding to the Locate message.

omniORB does not implement that, though. The place to implement it
would be in omniOrbPOA::objectExists in poa.cc. For the sake of one
extra network round trip, I'm not sure it's worth adding the
complexity.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --