[omniORB] Short identifier for objects?

Keeley, Michael mkeeley@orchestream.com
Fri, 5 Oct 2001 16:36:34 +0100


Duncan, 

Thanks very much for that, the object key al-la catior -x should work fine.
Are they always 12 bytes (for omniORB2.8, on a particular platform)?

> What bit of the interaction are you trying to replay?

Our corba components are arranged in a chain of processes, the UI at the
start, followed by various processing/distribution units, and finally a
worker.
The plan is to do something in the UI, and record what happens to the
worker.
Then we can 'replay' the CORBA calls to the worker without having to have
the UI/processing chain running.

MikeK.

-----Original Message-----
From: Duncan Grisby [mailto:dgrisby@uk.research.att.com]
Sent: 05 October 2001 15:48
To: Keeley, Michael
Cc: 'omniorb-list@uk.research.att.com'
Subject: Re: [omniORB] Short identifier for objects? 


On Thursday 4 October, "Keeley, Michael" wrote:

> I am in the process of writing a "replay tool" that can emulate one side
of
> a CORBA conversation from one recorded previously. (This is to enhace our
> component testing abilities).

OK.

> It's not required to be an all-singing, all-dancing, robust,
> works-with-any-orb tool, just as long as it can do the basics using
omniORB
> 2.8, we'll be fine.

I'm glad you said that.

> One of the tricks is to identify objects as they are passed back and forth
> across the wire, and to match them up during replay. So that when object
> Apple from process Eve is returned to process Adam, and then later on Adam
> makes a call on the Apple (er... Eat for example), the two recorded
objects
> can be matched successfully.
> The recording is done at Adam's end, so the return value from Adam: apple
=
> Eve->GetApple() is output using the IOR of the Apple. Later on the Adam:
> apple->Eat() call causes the IOR of apple to be output. The replay tool
> compares the IOR strings to get a match.

I'm not sure I completely understand what you are doing, but never
mind. What bit of the interaction are you trying to replay?

> I know that you are not *supposed* to compare IOR string directly.
However,
> as they are both output from the same instance of a process, they will be
> the same, right?

Wrong, I'm afraid. IORs contain some padding bytes that are not
initialised by the ORB, so two IOR strings for the same object,
created one after the other, may differ.

> IORs are unweildy to use in this manner, especially for high volumes of
> calls.
> Is there a smaller thing that I can get that will be unique for a given
> object and process? (The servant for the object may not be in the same
> process). 

Like I say, I don't completely understand what you are trying to
achieve.

However, given that you say you are happy for a solution that isn't at
all robust, you might like to look at the source for catior in
src/appl/utils/catior.cc. That extracts the information about host,
port and object key from an IOR, which may be sufficient for what you
want.

In the general case, poking inside IORs is a very dangerous thing to
do, and you're asking for all sorts of pain. It's quite possible to
have two totally different IORs that refer to the same object, for
example. In your case, though, you'll probably get away with it. It's
certainly better than comparing IOR strings.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --


--
This communication contains confidential information intended solely for the use of the individual/s and/or entity or entities to whom it was intended to be addressed.  If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this transmission is prohibited.  If you have received this communication in error, please contact the sender immediately, delete this communication from your system, and do not disclose its contents to any third party, or use its contents.  Any opinions expressed are solely those of the author and do not necessarily represent those of Orchestream Ltd or its group of companies unless otherwise specifically stated.