Discussion:
[omniORB] Multi-profile IOR
Tatiana Lazareva
2011-09-28 17:52:10 UTC
Permalink
Hi all,
I have a question about multi-profile IOR. I use the following
CORBA: omniORB-4.1.4.tar.gz under Solaris 10.
When I try register servants using the multiple-profile IOR I got an
exception: TRANSIENT. Does my CORBA support registration with
multiple-profile IOR? If yes, can you explain how should I perform servant
registration using the multiple IOR?
--
Cheers,

*T*atiana *L*azareva**

e-mail (regular): ****@gmail.com*

e-mail (office): ****@mera.ru*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20110928/31745bd2/attachment.htm
evgeni.rojkov at durr.com ()
2011-09-28 19:17:17 UTC
Permalink
Hi Tania,
it's no difference registering IORs by the NameService if single- or
multi-profile.
Does your client get TRANSIENT exception?
Do you use different ORB for client?
For example javaIDL (java 2 version) doesn't handle client calls to servants
located using multi-profiles IORs correctly.
Could it be your problem?
Regards, Evgeni


________________________________

Von: omniorb-list-***@omniorb-support.com
[mailto:omniorb-list-***@omniorb-support.com] Im Auftrag von Tatiana
Lazareva
Gesendet: Mittwoch, 28. September 2011 13:52
An: omniorb-***@omniorb-support.com
Betreff: [omniORB] Multi-profile IOR


Hi all,
I have a question about multi-profile IOR. I use the following CORBA:
omniORB-4.1.4.tar.gz under Solaris 10.
When I try register servants using the multiple-profile IOR I got an exception:
TRANSIENT. Does my CORBA support registration with multiple-profile IOR? If yes,
can you explain how should I perform servant registration using the multiple
IOR?
--
Cheers,

Tatiana Lazareva

e-mail (regular): ***@gmail.com

e-mail (office): ***@mera.ru


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20110928/202c7582/attachment.htm
Tatiana Lazareva
2011-09-28 19:25:27 UTC
Permalink
Evgeni,
Yes, my client get TRANSIENT exception in multi-profile IOR case.
For example, when I use single IOR:
/omcvobs/simbsso3g/external/omniORB/solaris/build/bin/catior
IOR:000000000000002b49444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e30000000000001000000000000007c0001020000000019666538303a3a3230333a626166663a666535373a3565396400000af90000000b4e616d6553657276696365000000000300000000000000080000000041545400000000010000001c0000000000010001000000010501000100010109000000010001010941545403000000084e8313b0a8090001
Type ID: "IDL:omg.org/CosNaming/NamingContextExt:1.0"
Profiles:
1. IIOP 1.2 fe80::203:baff:fe57:5e9d 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_OMNIORB_PERSISTENT_ID 4e8313b0a8090001

the registration is successfully performed, but if I use dual IOR:
/omcvobs/simbsso3g/external/omniORB/solaris/build/bin/catior
IOR:000000000000002B49444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578744578743A312E3000000000000200000000000000A400010200000000103139322E3136382E3230372E313100003A9800000000001F5374616E646172644E532F4E616D655365727665722D504F412F5F726F6F7400000000030000000000000008000000004A414300000000010000002000000000000100010000000105010001000101090000000205010001000101000000000100000020000000000001000100000001050100010001010900000002050100010001010000000000000000B80001020000000024666538303A3030303A303030303A30303A3230333A626166663A666535373A35653964003A9800000000001F5374616E646172644E532F4E616D655365727665722D504F412F5F726F6F7400000000030000000000000008000000004A4143000000000100000020000000000001000100000001050100010001010900000002050100010001010000000001000000200000000000010001000000010501000100010109000000020501000100010100
Type ID: "IDL:omg.org/CosNaming/NamingContextExt:1.0"
Profiles:
1. IIOP 1.2 192.168.207.11 15000 "StandardNS/NameServer-POA/_root"
TAG_ORB_TYPE 0x4a414300
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: 0x05010001, 0x00010100

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: 0x05010001, 0x00010100


2. IIOP 1.2 fe80:000:0000:00:203:baff:fe57:5e9d 15000
"StandardNS/NameServer-POA/_root"
TAG_ORB_TYPE 0x4a414300
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: 0x05010001, 0x00010100

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: 0x05010001, 0x00010100

the registration fails due to TRANSIENT exception.
I use the ORB in both case. Could you please explain what are the reasons
possible?
Post by evgeni.rojkov at durr.com ()
**
Hi Tania,
it's no difference registering IORs by the NameService if single- or
multi-profile.
Does your client get TRANSIENT exception?
Do you use different ORB for client?
For example javaIDL (java 2 version) doesn't handle client calls to
servants located using multi-profiles IORs correctly.
Could it be your problem?
Regards, Evgeni
------------------------------
Lazareva
*Gesendet:* Mittwoch, 28. September 2011 13:52
*Betreff:* [omniORB] Multi-profile IOR
Hi all,
I have a question about multi-profile IOR. I use the following
CORBA: omniORB-4.1.4.tar.gz under Solaris 10.
When I try register servants using the multiple-profile IOR I got an
exception: TRANSIENT. Does my CORBA support registration with
multiple-profile IOR? If yes, can you explain how should I perform servant
registration using the multiple IOR?
--
Cheers,
*T*atiana *L*azareva**
--
Cheers,

*T*atiana *L*azareva**

e-mail (regular): ****@gmail.com*

e-mail (office): ****@mera.ru*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20110928/31a08631/attachment-0001.htm
Tatiana Lazareva
2011-09-28 19:34:10 UTC
Permalink
Post by Tatiana Lazareva
Evgeni,
Yes, my client get TRANSIENT exception in multi-profile IOR case.
/omcvobs/simbsso3g/external/omniORB/solaris/build/bin/catior
IOR:000000000000002b49444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e30000000000001000000000000007c0001020000000019666538303a3a3230333a626166663a666535373a3565396400000af90000000b4e616d6553657276696365000000000300000000000000080000000041545400000000010000001c0000000000010001000000010501000100010109000000010001010941545403000000084e8313b0a8090001
Type ID: "IDL:omg.org/CosNaming/NamingContextExt:1.0"
1. IIOP 1.2 fe80::203:baff:fe57:5e9d 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_OMNIORB_PERSISTENT_ID 4e8313b0a8090001
/omcvobs/simbsso3g/external/omniORB/solaris/build/bin/catior
IOR:000000000000002B49444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578744578743A312E3000000000000200000000000000A400010200000000103139322E3136382E3230372E313100003A9800000000001F5374616E646172644E532F4E616D655365727665722D504F412F5F726F6F7400000000030000000000000008000000004A414300000000010000002000000000000100010000000105010001000101090000000205010001000101000000000100000020000000000001000100000001050100010001010900000002050100010001010000000000000000B80001020000000024666538303A3030303A303030303A30303A3230333A626166663A666535373A35653964003A9800000000001F5374616E646172644E532F4E616D655365727665722D504F412F5F726F6F7400000000030000000000000008000000004A4143000000000100000020000000000001000100000001050100010001010900000002050100010001010000000001000000200000000000010001000000010501000100010109000000020501000100010100
Type ID: "IDL:omg.org/CosNaming/NamingContextExt:1.0"
1. IIOP 1.2 192.168.207.11 15000 "StandardNS/NameServer-POA/_root"
TAG_ORB_TYPE 0x4a414300
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: 0x05010001, 0x00010100
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: 0x05010001, 0x00010100
2. IIOP 1.2 fe80:000:0000:00:203:baff:fe57:5e9d 15000
"StandardNS/NameServer-POA/_root"
TAG_ORB_TYPE 0x4a414300
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: 0x05010001, 0x00010100
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: 0x05010001, 0x00010100
the registration fails due to TRANSIENT exception.
I use the *[TL]*same ORB in both case. *[TL]*And I am sure that the
problem with my client but I cannot understand the reasons.Could you
please explain what are the reasons possible?
**
Post by evgeni.rojkov at durr.com ()
Hi Tania,
it's no difference registering IORs by the NameService if single- or
multi-profile.
Does your client get TRANSIENT exception?
Do you use different ORB for client?
For example javaIDL (java 2 version) doesn't handle client calls to
servants located using multi-profiles IORs correctly.
Could it be your problem?
Regards, Evgeni
------------------------------
Lazareva
*Gesendet:* Mittwoch, 28. September 2011 13:52
*Betreff:* [omniORB] Multi-profile IOR
Hi all,
I have a question about multi-profile IOR. I use the following
CORBA: omniORB-4.1.4.tar.gz under Solaris 10.
When I try register servants using the multiple-profile IOR I got an
exception: TRANSIENT. Does my CORBA support registration with
multiple-profile IOR? If yes, can you explain how should I perform
servant registration using the multiple IOR?
--
Cheers,
*T*atiana *L*azareva**
--
Cheers,
*T*atiana *L*azareva**
--
Cheers,

*T*atiana *L*azareva**

e-mail (regular): ****@gmail.com*

e-mail (office): ****@mera.ru*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20110928/9f41658f/attachment.htm
Duncan Grisby
2011-09-29 14:48:14 UTC
Permalink
Post by Tatiana Lazareva
Yes, my client get TRANSIENT exception in multi-profile IOR case.
/omcvobs/simbsso3g/external/omniORB/solaris/build/bin/catior
IOR:000000000000002b49444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e30000000000001000000000000007c0001020000000019666538303a3a3230333a626166663a666535373a3565396400000af90000000b4e616d6553657276696365000000000300000000000000080000000041545400000000010000001c0000000000010001000000010501000100010109000000010001010941545403000000084e8313b0a8090001
Type ID: "IDL:omg.org/CosNaming/NamingContextExt:1.0"
1. IIOP 1.2 fe80::203:baff:fe57:5e9d 2809 "NameService"
TAG_ORB_TYPE omniORB
I'm rather surprised by this -- that's a link-local IPv6 address, which
won't work in most circumstances, and omniORB should not have published
it in its IOR. How did you configure omniNames?
Post by Tatiana Lazareva
/omcvobs/simbsso3g/external/omniORB/solaris/build/bin/catior
IOR:000000000000002B49444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578744578743A312E3000000000000200000000000000A400010200000000103139322E3136382E3230372E313100003A9800000000001F5374616E646172644E532F4E616D655365727665722D504F412F5F726F6F7400000000030000000000000008000000004A414300000000010000002000000000000100010000000105010001000101090000000205010001000101000000000100000020000000000001000100000001050100010001010900000002050100010001010000000000000000B80001020000000024666538303A3030303A303030303A30303A3230333A626166663A666535373A35653964003A9800000000001F5374616E646172644E532F4E616D655365727665722D504F412F5F726F6F7400000000030000000000000008000000004A4143000000000100000020000000000001000100000001050100010001010900000002050100010001010000000001000000200000000000010001000000010501000100010109000000020501000100010100
Type ID: "IDL:omg.org/CosNaming/NamingContextExt:1.0"
1. IIOP 1.2 192.168.207.11 15000 "StandardNS/NameServer-POA/_root"
TAG_ORB_TYPE 0x4a414300
This is a JacORB naming service.

[...]
Post by Tatiana Lazareva
2. IIOP 1.2 fe80:000:0000:00:203:baff:fe57:5e9d 15000
"StandardNS/NameServer-POA/_root"
It has two IIOP profiles in it, which is not the correct way to
represent multiple IP addresses -- they should be in a single IIOP
profile with a TAG_ALTERNATE_IIOP_ADDRESS entry. That may or may not be
the problem.

Please get a trace from your client with -ORBtraceLevel 25. That will
show what's going on.

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --
evgeni.rojkov at durr.com ()
2011-09-29 16:29:23 UTC
Permalink
why do you need IORs for ?
could try "corbanames" like NameService=corbaname::customer_host:2809 with
omni::omniURI::stringToObject()
I do not have problems accessing JacOrb NameService with omniORB clients
Regards, Evgeni

________________________________

Von: Tatiana Lazareva [mailto:***@gmail.com]
Gesendet: Donnerstag, 29. September 2011 11:32
An: Duncan Grisby
Cc: Rojkov, Evgeni; omniorb-***@omniorb-support.com
Betreff: Re: [omniORB] Multi-profile IOR


Hi Duncan,
see inline please
Post by Tatiana Lazareva
Yes, my client get TRANSIENT exception in multi-profile IOR case.
/omcvobs/simbsso3g/external/omniORB/solaris/build/bin/catior
IOR:000000000000002b49444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f
6e746578744578743a312e30000000000001000000000000007c0001020000000019666538303a3a
3230333a626166663a666535373a3565396400000af90000000b4e616d6553657276696365000000
000300000000000000080000000041545400000000010000001c0000000000010001000000010501
000100010109000000010001010941545403000000084e8313b0a8090001
Post by Tatiana Lazareva
Type ID: "IDL:omg.org/CosNaming/NamingContextExt:1.0"
1. IIOP 1.2 fe80::203:baff:fe57:5e9d 2809 "NameService"
TAG_ORB_TYPE omniORB
I'm rather surprised by this -- that's a link-local IPv6 address, which
won't work in most circumstances, and omniORB should not have published
it in its IOR. How did you configure omniNames?

[TL] I use the default cfg for v4.0 or later, but fro IPv6 support I use
omniORB 4.1.4.
Post by Tatiana Lazareva
/omcvobs/simbsso3g/external/omniORB/solaris/build/bin/catior
IOR:000000000000002B49444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F
6E746578744578743A312E3000000000000200000000000000A400010200000000103139322E3136
382E3230372E313100003A9800000000001F5374616E646172644E532F4E616D655365727665722D
504F412F5F726F6F7400000000030000000000000008000000004A41430000000001000000200000
00000001000100000001050100010001010900000002050100010001010000000001000000200000
00000001000100000001050100010001010900000002050100010001010000000000000000B80001
020000000024666538303A3030303A303030303A30303A3230333A626166663A666535373A356539
64003A9800000000001F5374616E646172644E532F4E616D655365727665722D504F412F5F726F6F
7400000000030000000000000008000000004A414300000000010000002000000000000100010000
00010501000100010109000000020501000100010100000000010000002000000000000100010000
00010501000100010109000000020501000100010100
Post by Tatiana Lazareva
Type ID: "IDL:omg.org/CosNaming/NamingContextExt:1.0"
1. IIOP 1.2 192.168.207.11 15000 "StandardNS/NameServer-POA/_root"
TAG_ORB_TYPE 0x4a414300
This is a JacORB naming service.
[TL] Yes, I know. Also, I know that server use jacORB and I have the
example of dual and single IOR from. But I have no access to customer server and
because of it I should generate my own IOR with my IP addresses. Unfortunately,
I can not find tool for multiple-profile IOR generation and because of it I
create my IOR using the customer IOR manually. Can you suggest me the ways to
generate multiple-profile IOR if you know? So, I use the naming service the same
as the customer use(JacORB). My server and client work successfully with my
single IOR, my catior understand both of these IORs (my single and dual IOR, and
customers' too). Moreover, my client (based on omniORB )must work with customer
server (base on jacORB). But, my client can not perform registration with dual
IOR. Also I debugged my code and understood that TRANSIENT exception is caught
during the "::CORBA::Object_ptr resolve(const ::CosNaming::Name& n);" function
execution.


[...]
Post by Tatiana Lazareva
2. IIOP 1.2 fe80:000:0000:00:203:baff:fe57:5e9d 15000
"StandardNS/NameServer-POA/_root"
It has two IIOP profiles in it, which is not the correct way to
represent multiple IP addresses -- they should be in a single IIOP
profile with a TAG_ALTERNATE_IIOP_ADDRESS entry. That may or may not be
the problem.

[TL] The customer prefer use multiple-profile IOR. So my client must
work with IORs that I sent...


Please get a trace from your client with -ORBtraceLevel 25. That will
show what's going on.

[TL] I use my own client implemented using th omniORB library. I can not
have logs that you need. May be you mean server logs? I can configure this
parameter for omniORB server and for dual IOR it does not receive anything. But
for single IOR (the registration is performed) and the server log look like
this:



sunplant:yumanova:neos_blu8.1-04.c_solaris_dev_yumanova:~>
/opt/al/NEOS_TAT5/env/NEOS_BLU9.0-02.a/omniNames/bin/omniNames.sh
/opt/al/NEOS_TAT5/env/NEOS_BLU9.0-02.a/omniNames/bin /out

Starting the omniNames CORBA name service...


Setting the LD_LIBRARY_PATH environment variable...

LD_LIBRARY_PATH =
/opt/al/NEOS_TAT5/env/NEOS_BLU9.0-02.a/omniNames/bin/../lib

Setting the output directory for omniNames...

Output directory for omniNames was set to /out

Setting the config file for omniNames...

Config file for omniNames was set to
/opt/al/NEOS_TAT5/env/NEOS_BLU9.0-02.a/omniNames/bin/../config/omniORB.cfg

/opt/al/NEOS_TAT5/env/NEOS_BLU9.0-02.a/omniNames/bin/omniNames
-start

omniORB: Version: 4.1.4

omniORB: Distribution date: Sun Jul 19 18:35:23 BST 2009 dgrisby

omniORB: Skip link local address fe80::203:baff:fe57:5e9d on
interface bge0.

omniORB: My addresses are:

omniORB: 127.0.0.1

omniORB: 192.168.207.11

omniORB: ::1

omniORB: Maximum supported GIOP version is 1.2

omniORB: Native char code sets: UTF-8 ISO-8859-1.

omniORB: Transmission char code sets: UTF-8(1.2) UTF-8(1.1)
ISO-8859-1(1.2) ISO-8859-1(1.1) ISO-8859-1(1.0).

omniORB: Native wide char code sets: UTF-16.

omniORB: Transmission wide char code sets: UTF-16(1.2).

omniORB: Information: the omniDynamic library is not linked.

omniORB: Current configuration is as follows:

omniORB: DefaultInitRef (file) =

omniORB: DefaultInitRef (args) =

omniORB: InitRef = NameService=corbaname::192.168.102.24

omniORB: abortOnInternalError = 0

omniORB: abortOnNativeException = 0

omniORB: acceptBiDirectionalGIOP = 0

omniORB: acceptMisalignedTcIndirections = 0

omniORB: bootstrapAgentHostname =

omniORB: bootstrapAgentPort = 900

omniORB: clientCallTimeOutPeriod = 0

omniORB: clientConnectTimeOutPeriod = 0

omniORB: clientTransportRule = * unix,ssl,tcp

omniORB: configFile =
/opt/al/NEOS_TAT5/env/NEOS_BLU9.0-02.a/omniNames/bin/../config/omniORB.cfg

omniORB: connectionWatchImmediate = 0

omniORB: connectionWatchPeriod = 50000

omniORB: copyValuesInLocalCalls = 1

omniORB: diiThrowsSysExceptions = 0

omniORB: dumpConfiguration = 0

omniORB: endPoint = giop:tcp::2809

omniORB: endPointPublish = addr

omniORB: giopMaxMsgSize = 2097152

omniORB: giopTargetAddressMode = KeyAddr

omniORB: id = omniORB4

omniORB: idleThreadTimeout = 10

omniORB: immediateAddressSwitch = 0

omniORB: inConScanPeriod = 180

omniORB: lcdMode = 0

omniORB: maxGIOPConnectionPerServer = 5

omniORB: maxGIOPVersion = 1.2

omniORB: maxInterleavedCallsPerConnection = 5

omniORB: maxServerThreadPerConnection = 100

omniORB: maxServerThreadPoolSize = 100

omniORB: maxSocketRecv = 2147483647

omniORB: maxSocketSend = 2147483647

omniORB: nativeCharCodeSet = ISO-8859-1

omniORB: nativeWCharCodeSet = UTF-16

omniORB: objectTableSize = 0

omniORB: offerBiDirectionalGIOP = 0

omniORB: oneCallPerConnection = 1

omniORB: outConScanPeriod = 120

omniORB: poaHoldRequestTimeout = 0

omniORB: poaUniquePersistentSystemIds = 1

omniORB: principal = [Null]

omniORB: resetTimeOutOnRetries = 0

omniORB: scanGranularity = 5

omniORB: serverCallTimeOutPeriod = 0

omniORB: serverTransportRule = * unix,ssl,tcp

omniORB: socketSendBuffer = -1

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

omniORB: traceFile = [stderr]

omniORB: traceInvocationReturns = 0

omniORB: traceInvocations = 0

omniORB: traceLevel = 25

omniORB: traceThreadId = 0

omniORB: traceTime = 0

omniORB: unixTransportDirectory = /tmp/omni-%u

omniORB: unixTransportPermission = 777

omniORB: useTypeCodeIndirections = 1

omniORB: validateUTF8 = 0

omniORB: verifyObjectExistsAndType = 1

omniORB: Initialising incoming endpoints.

omniORB: Instantiate endpoint 'giop:tcp::2809'

omniORB: Bind to address :: port 2809.

omniORB: Publish specification: 'addr'

omniORB: Try to publish 'addr' for endpoint
giop:tcp:192.168.207.11:2809

omniORB: Publish endpoint 'giop:tcp:192.168.207.11:2809'

omniORB: Starting serving incoming endpoints.

omniORB: AsyncInvoker: thread id = 1 has started. Total threads
= 1

omniORB: giopRendezvouser task execute for
giop:tcp:192.168.207.11:2809


Thu Sep 29 13:30:58 2011:


Starting omniNames for the first time.

omniORB: Creating ref to in process: root/<4e843ad2722c0001/0>

target id : IDL:omg.org/CORBA/Object:1.0

most derived id:

omniORB: ObjRef() -- deleted.

Wrote initial log file.

omniORB: Persistent server identifier: 4e843ad2722c0001

omniORB: Adding key<NameService> (activating) to object table.

omniORB: State key<NameService> (activating) -> active

Read log file successfully.

omniORB: Creating ref to local: key<NameService>

target id : IDL:omg.org/CosNaming/NamingContextExt:1.0

most derived id: IDL:omg.org/CosNaming/NamingContextExt:1.0

Root context is
IOR:000000000000002b49444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f
6e746578744578743a312e300000000000010000000000000074000102000000000f3139322e3136
382e3230372e313100000af900000000000b4e616d65536572766963650000000003000000000000
00080000000041545400000000010000001c00000000000100010000000105010001000101090000
00010001010941545403000000084e843ad2722c0001

Checkpointing Phase 1: Prepare.

Checkpointing Phase 2: Commit.

Checkpointing completed.

omniORB: SocketCollection idle. Sleeping.

omniORB: Server accepted connection from
giop:tcp:[::ffff:127.0.0.1]:35984

omniORB: AsyncInvoker: thread id = 2 has started. Total threads
= 2

omniORB: Scavenger task execute.

omniORB: AsyncInvoker: thread id = 3 has started. Total threads
= 3

omniORB: giopWorker task execute.

omniORB: Accepted connection from
giop:tcp:[::ffff:127.0.0.1]:35984 because of this rule: "* unix,ssl,tcp"

omniORB: inputMessage: from giop:tcp:[::ffff:127.0.0.1]:35984
100 bytes

omniORB: sendChunk: to giop:tcp:[::ffff:127.0.0.1]:35984 25
bytes

omniORB: inputMessage: from giop:tcp:[::ffff:127.0.0.1]:35984 93
bytes

omniORB: Creating ref to in process: root/<4e843ad2722c0001/1>

target id : IDL:omg.org/CORBA/Object:1.0

most derived id: IDL:omg.org/CosNaming/NamingContext:1.0

omniORB: Adding root/<4e843ad2722c0001/1> (activating) to object
table.

omniORB: State root/<4e843ad2722c0001/1> (activating) -> active

omniORB: Creating ref to local: root/<4e843ad2722c0001/1>

target id : IDL:omg.org/CosNaming/NamingContextExt:1.0

most derived id: IDL:omg.org/CosNaming/NamingContextExt:1.0

omniORB: ObjRef(IDL:omg.org/CosNaming/NamingContext:1.0) --
deleted.

omniORB: createLocalObjRef -- reusing reference from local ref
list.

omniORB: sendChunk: to giop:tcp:[::ffff:127.0.0.1]:35984 204
bytes

omniORB: Server accepted connection from
giop:tcp:[::ffff:192.168.207.11]:35985

omniORB: AsyncInvoker: thread id = 4 has started. Total threads
= 4

omniORB: giopWorker task execute.

omniORB: Accepted connection from
giop:tcp:[::ffff:192.168.207.11]:35985 because of this rule: "* unix,ssl,tcp"

omniORB: inputMessage: from
giop:tcp:[::ffff:192.168.207.11]:35985 38 bytes

omniORB: Handling a GIOP LOCATE_REQUEST.

omniORB: sendChunk: to giop:tcp:[::ffff:192.168.207.11]:35985 20
bytes

omniORB: inputMessage: from
giop:tcp:[::ffff:192.168.207.11]:35985 117 bytes

omniORB: Receive codeset service context and set TCS to
(ISO-8859-1,UTF-16)

omniORB: Creating ref to in process: root/<4e843ad2722c0001/2>

target id : IDL:omg.org/CORBA/Object:1.0

most derived id: IDL:omg.org/CosNaming/NamingContext:1.0

omniORB: Adding root/<4e843ad2722c0001/2> (activating) to object
table.

omniORB: State root/<4e843ad2722c0001/2> (activating) -> active

omniORB: Creating ref to local: root/<4e843ad2722c0001/2>

t

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20110929/c8e94416/attachment-0001.htm
Duncan Grisby
2011-09-29 16:42:41 UTC
Permalink
On Thu, 2011-09-29 at 13:32 +0400, Tatiana Lazareva wrote:

[...]
Post by Duncan Grisby
This is a JacORB naming service.
[TL] Yes, I know. Also, I know that server use jacORB and I
have the example of dual and single IOR from. But I have no
access to customer server and because of it I should generate
my own IOR with my IP addresses.
I don't understand what you are doing. Can you be really clear
step-by-step what exactly you are doing?
Post by Duncan Grisby
Please get a trace from your client with -ORBtraceLevel 25. That will
show what's going on.
[TL] I use my own client implemented using th omniORB library.
I can not have logs that you need.
Why can't you provide the logs from your client?! The client is where
the problem appears, so if we can't see that, we have no way to help
understand the issue.
Post by Duncan Grisby
May be you mean server logs? I can configure this parameter
for omniORB server and for dual IOR it does not receive
anything. But for single IOR (the registration is performed)
That shows a perfectly happy looking omniNames...

[...]
Post by Duncan Grisby
omniORB: Version: 4.1.4
omniORB: Distribution date: Sun Jul 19 18:35:23 BST
2009 dgrisby
omniORB: Skip link local address
fe80::203:baff:fe57:5e9d on interface bge0.
This is why I'm surprised that you have an IOR with a link local address
in it -- omniORB specifically excludes them. I guess you manually built
an IOR with the link-local address in?

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --
Loading...