[omniORB] Problem connecting naming service

[Duncan Grisby]

On Tuesday 16 January, "Klaus Dieter Welast" wrote:

> On the other hand, I do same additional tests.
> Scenario: Master naming service is down, the slave naming server send
> his “LOCATION_FORWARD” reply to the master. Timeout period set
> the omniORB naming service client to 5 Secound .  The omniORB naming
> service client stops trying to connect the master server after that
> time period.  The trace below shows, that omniORB try to go back to
> the slave server, but stops trying this with
> “TRANSIENT_CallTimedout”. I think, omniORB should start this
> with a new full timeout period.

The looping that's happening in the trace is a result of a bug that has
been fixed. Update to omniORB 4.1.0 or the latest snapshot of 4.0.x to
avoid that issue. The problem there is that the failed call on the
forwarded object reference does not correctly fall back to using the
original reference.

However, even with the fix, I think you'll see the invocations bounce
between the master and location forwarded slave because of Visibroker's
object references.

[...]
> Answer from Borland:

[...]
> 2.  Refer to 13.6.7 Profile and Component Composition in IORs on page 454.
> 
> It states the following
> 
> a.    Profiles must be independent, complete, and self-contained. Their
> use shall not depend on information contained in another profile.

> b.	Any invocation uses information from exactly one profile. 

> c.    Unless otherwise specified in the definition of a particular
> profile, multiple profiles with the same profile tag may be included
> in an IOR.
> 
> Visibroker 7 ORB provides 2 independent IIOP profiles.  Each IIOP
> profile is complete, independent and self-contained.  When the naming
> service fails over, the client will uses the slave IIOP profile.

I still maintain that omniORB's behaviour is correct. As point b above
says, "any invocation uses information from exactly one profile". You
are doing one invocation. omniORB is using one profile. I think omniORB
is correct to ignore the second profile when it is doing an invocation.


> 3.  Refer to 13.6.3 IOR Profiles on page 448
> 
> It states the following:
> 
> Object References have at least one tag profile.  Each profile support
> one or more protocols and encapsulates all information the protocols
> it supports need to identify the object.
> 
> Therefore, Borland Visibroker 7 is compliant on this clause.

Indeed.

> The specification also states the following:
> 
> Interoperability issues can arise when an ORB sends an IOR with
> multiple profiles to the receiving ORB, and the receiving ORB returns
> a derived reference to the object, which has profiles or profile
> component data removed or transformed from the original IOR contents.
> 
> Full IOR conformance requires that an orb which receives an IOR for an
> object passed to it through the GIOP shall recover the original IOR,
> in its entirety, for passing as a reference to that object from that
> orb through the same protocol

When omniORB passes object references along, it _does_ maintain all the
profiles, so it _does_ have full IOR conformance. Full IOR conformance
does not say that an ORB must _use_ all the profiles, merely that it
should maintain them and pass them along. Indeed, the point b in section
13.6.7 specifically says an ORB should _not_ use all profiles, but
"exactly one".

[...]
> If OmniORB is certified at both CORBA 2.4 above, OmniORB client should
> use the Full IOR conformance and not remove the slave IIOP profile
> from the Visibroker clustered naming service.

omniORB does not remove the second IIOP profile. It leaves it there,
perfectly safe, and passes it on when the object reference is
transmitted.

Cheers,

Duncan.

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