[omniORB] LOCATION_FORWARD Replies & Client Connection Releas es

[Wilson Jimmy - jiwils]

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

Oops.  I was talking about omniORBpy.

Thanks for the clarification/information!

Jimmy
-- 
James "Jimmy" Wilson
Software Developer, Acxiom Corporation

-----Original Message-----
From: Duncan Grisby [mailto:duncan at grisby.org] 
Sent: Friday, February 04, 2005 7:16 AM
To: Wilson Jimmy - jiwils
Cc: omniorb-list at omniorb-support.com
Subject: Re: [omniORB] LOCATION_FORWARD Replies & Client Connection Releases


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


**********************************************************************
The information contained in this communication is
confidential, is intended only for the use of the recipient
named above, and may be legally privileged.
If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, 
distribution, or copying of this communication is strictly
prohibited.
If you have received this communication in error,
please re-send this communication to the sender and
delete the original message or any copy of it from your
computer system. Thank You.