[omniORB] Reverting object reference to original profile ques tion

[Lee, Robert C.]

Duncan,

I use JacORB on the client end of my app. The server end consists of
serveral servers all using OmniORB. The main server holds object reference
to the other corba objects (JacORB or omniORB) via a method that to the main
server passing in the object reference. Here's an example:

CORBA::Boolean
ExecMgr_i::registerAppMgr (
           const char* hostname,
           AppMgr_ptr app_mgr)
    throw  (Executive::ExecMgr::NilAppMgr)

What (and when) is a location forwarded object?  In my main server, one
corba object does hold a regular c++ pointer to another corba object. Both
Corba objects are accessed by the client GUI via a name lookup.

Thanks for your help/patience.

Robert

-----Original Message-----
From: Duncan Grisby [mailto:duncan at grisby.org]
Sent: Thursday, November 06, 2003 3:38 AM
To: Lee, Robert C.
Cc: 'omniorb-list at omniorb-support.com'
Subject: Re: [omniORB] Reverting object reference to original profile
question 


On Tuesday 4 November, "Lee, Robert C." wrote:

> I left a Corba server running all long, when I returned this morning, I
see
> the following output in the console window:
> 
> omniORB: Reverting object reference to original profile
> omniORB: Invocation on a location forwarded object has failed. 195
retries.
> omniORB: LocateRequest to remote:
> key<0x383833313638393731312f00112a302817343201334a>
> omniORB: throw giopStream::CommFailure from
> giopStream.cc:1061(0,NO,TRANSIENT_ConnectFailed)
> omniORB: Reverting object reference to original profile
> omniORB: Invocation on a location forwarded object has failed. 185
retries.
> omniORB: LocateRequest to remote: root<0>
> omniORB: throw giopStream::CommFailure from
> giopStream.cc:1061(0,NO,TRANSIENT_ConnectFailed)
> omniORB: Reverting object reference to original profile
> omniORB: Invocation on a location forwarded object has failed. 196
retries.
> 
> This server does hold IORs to other Corba objects and those other objects
in
> their respective servers were still running this morning. At any rate, no
> one was making calls on any of these objects at night. So I don't know
> what's wrong. 

Live object references can have two sets of profiles indicating where
the object is. The first comes from the IOR. If the object is location
forwarded, it gets another profile for the new location. If a call to
a location forwarded object fails, omniORB reverts to use the original
profile and tries again. It looks like each time it reverts to the
original profile, the remote ORB is forwarding it back to the same
location, which keeps failing, hence the loop.

What ORB is omniORB talking to?  The object key in the log does not
come from omniORB.

Cheers,

Duncan.

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