[omniORB] LOCATION_FORWARD Replies & Client Connection Releases

[Duncan Grisby]

On Thursday 3 February, Wilson Jimmy - jiwils wrote:

> I've been using omniORB since the 1.x versions, and I swear I remember that
> it used to behave a bit differently on the client side when given a
> LOCATION_FORWARD reply.

I think you have your versions mixed up. omniORB version 1 was never
released from ORL. omniORB 2.2 was the first ever public release.

> Before the 2.x versions, I thought that after a LOCATION_FORWARD was
> received and the connection to the new reference was made that omniORB would
> close the original socket connection.  Did this ever happen or was I
> dreaming?  It definitely does not seem to happen now.

I'm pretty certain omniORB has never closed connections immediately
after a location forward. It certainly doesn't in 3.0.x or 4.0.x.

> Curiously, would it be ok *if* an ORB behaved this way?  I can see that with
> a long running client application, this might be useful.  Granted setting
> the idle timeout will do the job, but doesn't the LOCATION_FORWARD almost
> imply that the original connection is not needed (if the forward reference
> is not located on the same host/port)?

It would be CORBA compliant, and for some applications it would be an OK
thing to do. For others it would be very bad. For example, I'm currently
working on a framework that returns a large number of object references,
all of which are location forwarded on the first invocation. If the
client was to close the connection to the original location after
contacting each object and being forwarded, there would be a huge amount
of overhead. What you suggest only makes sense if there is only one
object that is forwarded.

Cheers,

Duncan.

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