[omniORB] Problem connecting naming service
Klaus Dieter Welast
K.D.Welast at T-Online.de
Tue Jan 16 19:15:19 GMT 2007
Hello Duncan,
please, let me reopen the discussion about our problem by connecting the Visibroker naming service in master/slave configuration.
In the meantime I get an answer from Borland, you can see it below.
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.
Best regards
Kl. D. Welast
------------------------------------------------------------------
Answer from Borland:
I agree with you TAG_ALTERNATE_IIOP_ADRESS tag can be included in the IIOP profile for the clustered naming service. However, it is an optional tag and may not be implemented by all the compliant ORB vendors. As per design, Borland Visibroker 7.0 uses 1 or more IIOP profiles to represent the clustered naming service. I would like to highlight to you various sections of the specification.
1. Refer to 15.7.3 IIOP IOR Profile Components on page 551.
It states a list of mandatory and optional tags. TAG_ALTERNATE_IIOP_ADDRESS is listed as an optional tag for IIOP 1.2 conformance.
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.
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.
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
Limited Profile IOR conformance requires that an orb which receives an IOR passed to it through the GIOP, shall recover all of the standard information contained in the IOR profile for that protocol, whenever passing a reference to that object, using the same protocol, to anther orb.
Conformance to IIOP versions 1.0, 1.1, 1.2 only requires support of limited Profile IOR. Due to interoperability issues, limited profile IOR is deprecated by the CORBA 2.4 specification.
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.
References:
OmniORB Home Page: http://omniorb.sourceforge.net/
CORBA 2.6 specification: http://www.omg.org/cgi-bin/doc?formal/01-12-01
------------------------------------------------------
omniORB-Trace:
D:\Dev_Projekte\VC70\EchoCltNs\Debug>EchoCltNs.exe -ORBInitRef NameService=corbaname::164.23.185.14,:164.23.131.250 -ORBtraceLevel 40 -ORBclientCallTimeOutPeriod 5000
omniORB: Distribution date: Fri Jan 13 13:47:35 GMT 2006 dgrisby
omniORB: My addresses are:
omniORB: 164.23.185.14
omniORB: 127.0.0.1
omniORB: Maximum supported GIOP version is 1.2
omniORB: Native char code sets: ISO-8859-1 UTF-8.
omniORB: Transmission char code sets: ISO-8859-1(1.2) ISO-8859-1(1.1) ISO-8859-1(1.0) UTF-8(1.2) UTF-8(1.1).
omniORB: Native wide char code sets: UTF-16.
omniORB: Transmission wide char code sets: UTF-16(1.2).
omniORB: Initialising omniDynamic library.
omniORB: Current configuration is as follows:
omniORB: DefaultInitRef (file) =
omniORB: DefaultInitRef (args) =
omniORB: InitRef = NameService=corbaname::164.23.185.14,:164.23.131.250
omniORB: abortOnInternalError = 0
omniORB: abortOnNativeException = 0
omniORB: acceptBiDirectionalGIOP = 0
omniORB: acceptMisalignedTcIndirections = 0
omniORB: bootstrapAgentHostname =
omniORB: bootstrapAgentPort = 900
omniORB: clientCallTimeOutPeriod = 5000
omniORB: clientTransportRule = * unix,ssl,tcp
omniORB: configFile = [none]
omniORB: connectionWatchImmediate = 0
omniORB: connectionWatchPeriod = 50000
omniORB: diiThrowsSysExceptions = 0
omniORB: dumpConfiguration = 0
omniORB: endPoint = giop:tcp::
omniORB: endPointPublishAllIFs = 0
omniORB: giopMaxMsgSize = 2097152
omniORB: giopTargetAddressMode = KeyAddr
omniORB: id = omniORB4
omniORB: inConScanPeriod = 180
omniORB: lcdMode = 0
omniORB: maxGIOPConnectionPerServer = 5
omniORB: maxGIOPVersion = 1.2
omniORB: maxInterleavedCallsPerConnection = 5
omniORB: maxServerThreadPerConnection = 100
omniORB: maxServerThreadPoolSize = 100
omniORB: maxSocketRecv = 131072
omniORB: maxSocketSend = 131072
omniORB: nativeCharCodeSet = ISO-8859-1
omniORB: nativeWCharCodeSet = UTF-16
omniORB: objectTableSize = 0
omniORB: offerBiDirectionalGIOP = 0
omniORB: omniORB_27_CompatibleAnyExtraction = 0
omniORB: oneCallPerConnection = 1
omniORB: outConScanPeriod = 120
omniORB: poaHoldRequestTimeout = 0
omniORB: poaUniquePersistentSystemIds = 1
omniORB: principal = [Null]
omniORB: scanGranularity = 5
omniORB: serverCallTimeOutPeriod = 0
omniORB: serverTransportRule = * unix,ssl,tcp
omniORB: strictIIOP = 1
omniORB: supportBootstrapAgent = 0
omniORB: supportCurrent = 1
omniORB: supportPerThreadTimeOut = 0
omniORB: tcAliasExpand = 0
omniORB: threadPerConnectionLowerLimit = 9000
omniORB: threadPerConnectionPolicy = 1
omniORB: threadPerConnectionUpperLimit = 10000
omniORB: threadPoolWatchConnection = 1
omniORB: traceExceptions = 1
omniORB: traceFile = [stderr]
omniORB: traceInvocations = 1
omniORB: traceLevel = 40
omniORB: traceThreadId = 0
omniORB: unixTransportDirectory = /tmp/omni-%u
omniORB: unixTransportPermission = 777
omniORB: useTypeCodeIndirections = 1
omniORB: verifyObjectExistsAndType = 1
omniORB: Creating ref to remote: key<NameService>
target id : IDL:omg.org/CORBA/Object:1.0
most derived id:
omniORB: Initial reference `NameService' resolved from -ORBInitRef argument / ORB registration.
omniORB: Invoke '_is_a' on remote: key<NameService>
omniORB: AsyncInvoker: thread id = 1 has started. Total threads = 1
omniORB: Scavenger task execute.
omniORB: Client attempt to connect to giop:tcp:164.23.185.14:2809
omniORB: Switch rope to use address giop:tcp:164.23.131.250:2809
omniORB: throw giopStream::CommFailure from giopStream.cc:1077(1,NO,TRANSIENT_ConnectFailed)
omniORB: Invoke '_is_a' on remote: key<NameService>
omniORB: Client attempt to connect to giop:tcp:164.23.131.250:2809
omniORB: Client opened connection to giop:tcp:164.23.131.250:2809
omniORB: sendChunk: to giop:tcp:164.23.131.250:2809 100 bytes
omniORB:
4749 4f50 0100 0100 5800 0000 0000 0000 GIOP....X.......
0200 0000 01cd cdcd 0b00 0000 4e61 6d65 ............Name
5365 7276 6963 65cd 0600 0000 5f69 735f Service....._is_
6100 cdcd 0000 0000 2800 0000 4944 4c3a a.......(...IDL:
6f6d 672e 6f72 672f 436f 734e 616d 696e omg.org/CosNamin
672f 4e61 6d69 6e67 436f 6e74 6578 743a g/NamingContext:
312e 3000 1.0.
omniORB: inputMessage: from giop:tcp:164.23.131.250:2809 368 bytes
omniORB:
4749 4f50 0100 0101 6401 0000 0000 0000 GIOP....d.......
0200 0000 0300 0000 2b00 0000 4944 4c3a ........+...IDL:
6f6d 672e 6f72 672f 436f 734e 616d 696e omg.org/CosNamin
672f 4e61 6d69 6e67 436f 6e74 6578 7445 g/NamingContextE
7874 3a31 2e30 0000 0200 0000 0000 0000 xt:1.0..........
8800 0000 0001 0200 0000 000e 3136 342e ............164.
3233 2e31 3835 2e31 3400 0af9 0000 0025 23.185.14......%
0050 4d43 0000 0004 0000 0013 2f43 4f4e .PMC......../CON
5445 5854 5f50 4f41 4d61 7374 6572 0020 TEXT_POAMaster.
0000 0001 3200 0000 0000 0003 5649 5303 ....2.......VIS.
0000 0005 0007 0801 ff00 0000 0000 0000 ................
0000 0008 0000 0000 5649 5300 0000 0001 ........VIS.....
0000 0018 0000 0000 0001 0001 0000 0001 ................
0501 0001 0001 0109 0000 0000 0000 0000 ................
8c00 0000 0001 0200 0000 000f 3136 342e ............164.
3233 2e31 3331 2e32 3530 0000 0af9 0000 23.131.250......
0000 0025 0050 4d43 0000 0004 0000 0013 ...%.PMC........
2f43 4f4e 5445 5854 5f50 4f41 4d61 7374 /CONTEXT_POAMast
6572 0020 0000 0001 3200 0000 0000 0003 er. ....2.......
5649 5303 0000 0005 0007 0801 ff00 0000 VIS.............
0000 0000 0000 0008 0000 0000 5649 5300 ............VIS.
0000 0001 0000 0018 0000 0000 0001 0001 ................
0000 0001 0501 0001 0001 0109 0000 0000 ................
omniORB: Creating ref to remote: key<.PMC.........CONTEXT.POAMaster......2>
target id : IDL:omg.org/CORBA/Object:1.0
most derived id: IDL:omg.org/CosNaming/NamingContextExt:1.0
omniORB: GIOP::LOCATION_FORWARD -- retry request.
omniORB: omniRemoteIdentity deleted.
omniORB: ObjRef(IDL:omg.org/CosNaming/NamingContextExt:1.0) -- deleted.
omniORB: Invoke '_is_a' on remote: key<.PMC.........CONTEXT.POAMaster......2>
omniORB: Send codeset service context: (ISO-8859-1,UTF-16)
omniORB: Client attempt to connect to giop:tcp:164.23.185.14:2809
omniORB: throw giopStream::CommFailure from giopStream.cc:1077(1,NO,TRANSIENT_ConnectFailed)
omniORB: Invoke '_is_a' on remote: key<.PMC.........CONTEXT.POAMaster......2>
omniORB: Send codeset service context: (ISO-8859-1,UTF-16)
omniORB: Client attempt to connect to giop:tcp:164.23.185.14:2809
omniORB: Switch rope to use address giop:tcp:164.23.185.14:2809
omniORB: throw giopStream::CommFailure from giopStream.cc:1077(1,NO,TRANSIENT_ConnectFailed)
omniORB: Invoke '_is_a' on remote: key<.PMC.........CONTEXT.POAMaster......2>
omniORB: Send codeset service context: (ISO-8859-1,UTF-16)
omniORB: Client attempt to connect to giop:tcp:164.23.185.14:2809
omniORB: Switch rope to use address giop:tcp:164.23.185.14:2809
omniORB: throw giopStream::CommFailure from giopStream.cc:1077(1,NO,TRANSIENT_ConnectFailed)
omniORB: Invoke '_is_a' on remote: key<.PMC.........CONTEXT.POAMaster......2>
omniORB: Send codeset service context: (ISO-8859-1,UTF-16)
omniORB: Client attempt to connect to giop:tcp:164.23.185.14:2809
omniORB: Switch rope to use address giop:tcp:164.23.185.14:2809
omniORB: throw giopStream::CommFailure from giopStream.cc:1077(1,NO,TRANSIENT_ConnectFailed)
omniORB: Invoke '_is_a' on remote: key<.PMC.........CONTEXT.POAMaster......2>
omniORB: Send codeset service context: (ISO-8859-1,UTF-16)
omniORB: Client attempt to connect to giop:tcp:164.23.185.14:2809
omniORB: Client opened connection to giop:tcp:164.23.185.14:2809
omniORB: sendChunk: to giop:tcp:164.23.185.14:2809 148 bytes
omniORB:
4749 4f50 0102 0100 8800 0000 0200 0000 GIOP............
0300 0000 0000 cdcd 2500 0000 0050 4d43 ........%....PMC
0000 0004 0000 0013 2f43 4f4e 5445 5854 ......../CONTEXT
5f50 4f41 4d61 7374 6572 0020 0000 0001 _POAMaster. ....
32cd cdcd 0600 0000 5f69 735f 6100 cdcd 2......._is_a...
0100 0000 0100 0000 0c00 0000 0100 0000 ................
0100 0100 0901 0100 2800 0000 4944 4c3a ........(...IDL:
6f6d 672e 6f72 672f 436f 734e 616d 696e omg.org/CosNamin
672f 4e61 6d69 6e67 436f 6e74 6578 743a g/NamingContext:
312e 3000 1.0.
omniORB: Switch rope to use address giop:tcp:164.23.185.14:2809
omniORB: throw giopStream::CommFailure from giopStream.cc:1110(0,NO,TRANSIENT_CallTimedout)
omniORB: Client connection refcount = 0
omniORB: Client close connection to giop:tcp:164.23.185.14:2809
omniORB: Reverting object reference to original profile
omniORB: omniRemoteIdentity deleted.
omniORB: Invocation on a location forwarded object has failed. 0 retries.
omniORB: Scan for idle connections (1163759291,910000000)
omniORB: Scavenger reduce idle count for strand 006C3490 to 23
omniORB: Scan for idle connections done (1163759291,910000000).
omniORB: Invoke '_is_a' on remote: key<NameService>
omniORB: sendChunk: to giop:tcp:164.23.131.250:2809 100 bytes
omniORB:
4749 4f50 0100 0100 5800 0000 0000 0000 GIOP....X.......
0400 0000 01cd cdcd 0b00 0000 4e61 6d65 ............Name
5365 7276 6963 65cd 0600 0000 5f69 735f Service....._is_
6100 cdcd 0000 0000 2800 0000 4944 4c3a a.......(...IDL:
6f6d 672e 6f72 672f 436f 734e 616d 696e omg.org/CosNamin
672f 4e61 6d69 6e67 436f 6e74 6578 743a g/NamingContext:
312e 3000 1.0.
omniORB: throw giopStream::CommFailure from giopStream.cc:1110(0,NO,TRANSIENT_CallTimedout)
omniORB: Client connection refcount = 0
omniORB: Client close connection to giop:tcp:164.23.131.250:2809
omniORB: throw TRANSIENT from omniObjRef.cc:759 (NO,TRANSIENT_CallTimedout)
Caught CORBA::SystemException.
omniORB: omniRemoteIdentity deleted.
omniORB: ObjRef() -- deleted.
omniORB: ORB not destroyed; no final clean-up.
"Duncan Grisby" <duncan at grisby.org> schrieb:
> On Thursday 5 October, "K.D.Welast at t-online.de" wrote:
>
> [...]
> > I have done the test with 4.1.0 RC 1 and the problem is still there.
> > The version 4.1.0 RC 1 binaries are building with VC 7 SP1 on WinXP SP2
> >
> > Below the trace with -ORBtraceLevel 40 -ORBtraceInvocations 1 for the
> > versions 4.10 RC1 and 4.07
>
> OK, now I've looked at it closer, it's not the issue I thought it was at
> all. The problem is actually that Visibroker is returning a strange IOR
> in the location forward. Extracting it from the trace, and dumping it
> with catior, it looks like this:
>
> Type ID: "IDL:omg.org/CosNaming/NamingContextExt:1.0"
> Profiles:
> 1. IIOP 1.2 164.23.185.14 2809 ".PMC......../CONTEXT_POAMaster. ....2"
> unknown tag(0x56495303) 0x00070801ff
> TAG_ORB_TYPE 0x56495300
> TAG_CODE_SETS char native code set: ISO-8859-1
> char conversion code set: UTF-8
> wchar native code set: UTF-16
> wchar conversion code set:
>
>
> 2. IIOP 1.2 164.23.131.250 2809 ".PMC......../CONTEXT_POAMaster. ....2"
> unknown tag(0x56495303) 0x00070801ff
> TAG_ORB_TYPE 0x56495300
> TAG_CODE_SETS char native code set: ISO-8859-1
> char conversion code set: UTF-8
> wchar native code set: UTF-16
> wchar conversion code set:
>
>
> So you can see it has two IIOP profiles. The proper way to represent
> multiple IP addressees is with a TAG_ALTERNATE_IIOP_ADDRESS.
> Constructing an IOR with omniNames, it looks like this:
>
> Type ID: "IDL:omg.org/CosNaming/NamingContextExt:1.0"
> Profiles:
> 1. IIOP 1.2 164.23.185.14 2809 "NameService"
> TAG_ORB_TYPE omniORB
> TAG_CODE_SETS char native code set: ISO-8859-1
> char conversion code set: UTF-8
> wchar native code set: UTF-16
> wchar conversion code set: UTF-16
>
> TAG_ALTERNATE_IIOP_ADDRESS 164.23.131.250 2809
>
> You see it has just one IIOP profile, with two addresses in it. With an
> IOR like that, omniORB does the right thing.
>
> Clearly Visibroker is using both IIOP profiles. I think that's wrong
> according to the CORBA 2.6 spec. In section 13.6.3 is says:
>
> Object references have at least one tagged profile. Each profile
> supports one or more protocols and encapsulates all the basic
> information the protocols it supports need to identify an object. Any
> single profile holds enough information to drive a complete invocation
> using any of the protocols it supports; the content and structure of
> those profile entries are wholly specified by these protocols.
>
> Then in section 13.6.7, it says:
>
> The following rules augment the preceding discussion:
>
> 1. Profiles must be independent, complete, and self-contained. Their
> use shall not depend on information contained in another profile.
>
> 2. Any invocation uses information from exactly one profile.
>
> ...
>
> So based on point 2, I think omniORB is right to only use the details in
> the first IIOP profile, and ignore the second one. It wouldn't be hard
> to extend omniORB to use all the IIOP profiles when picking the
> endpoints to try, but I think the spec says it's wrong to do that.
>
> Cheers,
>
> Duncan.
>
> --
> -- Duncan Grisby --
> -- duncan at grisby.org --
> -- http://www.grisby.org --
>
--
Mit freundlichen Grüßen
Kl. D. Welast
Hellersberstr. 35A
41460 Neuss
Tel: +49 2131 166657
Mobil: +49 171 5638203
Email: k.d.welast at t-online.de
More information about the omniORB-list
mailing list