No subject

Discussion:

No subject

b***@does.not.exist.com

2012-08-31 11:19:44 UTC

information other than below:
omniORB: (?) Invoke 'register_entry' on remote: key<dname>
omniORB: (?) throw DATA_CONVERSION from cs-8bit.cc:257
(NO,DATA_CONVERSION_CannotMapChar)
omniORB: (?) Unexpected error encountered in talking to the server
giop:tcp:10.6.24.116:59747. The connection is closed immediately. GIOP_C
state 2, strand state 0
omniORB: (?) Client connection refcount = 0
omniORB: (?) Client close connection to giop:tcp:10.6.24.116:59747

Thanks.
Jingdong Sun
InfoSphere Streams Development
Phone 507 253-5958 (T/L 553-5958)
jindong at us.ibm.com

From: Duncan Grisby <duncan at grisby.org>
To: Jingdong Sun/Rochester/IBM at IBMUS,
Cc: omniorb-list <omniorb-list at omniorb-support.com>
Date: 09/14/2012 05:00 AM
Subject: Re: [omniORB] DATA_CONVERSION problem with omniORB 4.1.4

By some update, I am using IOR for client to set connection with
server. But problem still there.
1. From both client and server sides, at the ORB initial time, set
nativeCharCodeSet=UTF-8.
2.1. At server: run CORBA::ORB_init(argc, argv, "omniORB4") to create
a ORB object.
2.2. Using above ORB object for the server, and save IOR into string
by calling CORBA::Object_ptr->object_to_string(obj);
3.1: At client side, run CORBA::ORB_init(argc, argv, "omniORB4") to
create a ORB object too.
3.2. get saved IOR string for the server, and using it to set up
CORBA::Object_var _service_obj = _app_orb->string_to_object
(ior.c_str());
_narrow(_service_obj);

That certainly should work. Please post the IOR string you are using,
and a complete trace from the client from -ORBtraceLevel 25.

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

--=_alternative 004FC21286257A79_=
Content-Type: text/html; charset="US-ASCII"

Hi, Duncan,
 
 The IOR string as below:
 10 Sep 2012 17:26:05.215 [20218] INFO
:::NAM.StartupDaemon M[dnameserver.cpp:afterActivation:685]  - DN_NAM
Service IOR: 
    Type ID: IDL:NAM/NameService:1.0
 
 IIOP Profile
     Version:  1.2
     Address:  10.6.24.116:59747
    Location:  10.6.24.116:59747..ZNP..N......
         Key:  fe
ed 5a 4e 50 00 00 4e fa 00 00 00 00 00 
          
  TAG_ORB_TYPE omniORB
          
  TAG_CODE_SETS char native code set: UTF-8
          
                char conversion
code set: UTF-8
          
                wchar native code
set: UTF-16
          
                wchar conversion
code set: UTF-16
          
  
 
 From client side, I set traceLevel=40,
but could not find more useful information other than below:
 omniORB: (?) Invoke 'register_entry'
on remote: key<dname>
 omniORB: (?) throw DATA_CONVERSION
from cs-8bit.cc:257 (NO,DATA_CONVERSION_CannotMapChar)
 omniORB: (?) Unexpected error encountered
in talking to the server giop:tcp:10.6.24.116:59747. The connection is
closed immediately.  GIOP_C state 2, strand state 0
 omniORB: (?) Client connection refcount
= 0
 omniORB: (?) Client close connection
to giop:tcp:10.6.24.116:59747
 
 Thanks.
 Jingdong Sun 
InfoSphere Streams Development 
Phone  507 253-5958  (T/L 553-5958)   
jindong at us.ibm.com
 
 
 
 From:      
 Duncan Grisby <duncan at grisby.org>
 To:      
 Jingdong Sun/Rochester/IBM at IBMUS,

 Cc:      
 omniorb-list <omniorb-list at omniorb-support.com>
 Date:      
 09/14/2012 05:00 AM
 Subject:    
   Re: [omniORB]
DATA_CONVERSION problem with omniORB 4.1.4
 
<hr noshade>
 
 
 <tt>On Mon, 2012-09-10 at 12:41 -0500, Jingdong Sun wrote: 
 
> By some update, I am using IOR for client to set connection with 
> server. But problem still there. 
> 
> What I am doing as below: 
> 1. From both client and server sides, at the ORB initial time, set 
> nativeCharCodeSet=UTF-8. 
> 2.1. At server: run CORBA::ORB_init(argc, argv, "omniORB4")
to create 
> a ORB object. 
> 2.2. Using above ORB object for the server, and save IOR into string 
> by calling CORBA::Object_ptr->object_to_string(obj); 
> 3.1: At client side, run CORBA::ORB_init(argc, argv, "omniORB4")
to 
> create a ORB object too. 
> 3.2. get saved IOR string for the server, and using it to set up 
> client and server connection as below: 
>         CORBA::Object_var _service_obj = _app_orb->string_to_object 
> (ior.c_str()); 
>         _narrow(_service_obj); 
 
That certainly should work. Please post the IOR string you are using, 
and a complete trace from the client from -ORBtraceLevel 25. 
 
Duncan. 
 
-- 
-- Duncan Grisby         -- 
 -- duncan at grisby.org     -- 
  -- </tt><a href=http://www.grisby.org/><tt>http://www.grisby.org</tt></a><tt>
-- 
 
 
</tt>
 
--=_alternative 004FC21286257A79_=--

b***@does.not.exist.com

2012-08-31 11:19:44 UTC

Permalink

up some configs, such as nativeCharCodeSet. But with your comment, you
keep saying that the client codeset is affected by server IOR. So, if
client ORB setting and codeset info it get from server IOR are not match,
what will client follow?

Thanks.
Jingdong Sun
InfoSphere Streams Development
Phone 507 253-5958 (T/L 553-5958)
jindong at us.ibm.com

From: Duncan Grisby <duncan at grisby.org>
To: Jingdong Sun/Rochester/IBM at IBMUS,
Cc: omniorb-list <omniorb-list at omniorb-support.com>
Date: 09/18/2012 09:05 AM
Subject: Re: [omniORB] DATA_CONVERSION problem with omniORB 4.1.4

14 Sep 2012 17:45:38.403 [9509] INFO :::NAM.StartupDaemon
Type ID: IDL:NAM/NameService:1.0

That's not the IOR string. That's a decoded version of it. It's good
enough though.

[...]

Address: 10.6.24.116:48049
Location: 10.6.24.116:48049...SP..%%.....
Key: fe 82 a5 53 50 00 00 25 25 00 00 00 00 00

That is not the object reference that the log shows the client
attempting to use. This shows use of an object set with a corbaloc URI:

omniORB: (0) Creating ref to remote: key<dname>
target id : IDL:omg.org/CORBA/Object:1.0
most derived id:
omniORB: (0) Invoke '_is_a' on remote: key<dname>
omniORB: (0) Client attempt to connect to
giop:tcp:d0701b06.pok.hpc-ng.ibm.com:48049

The object reference has object key "dname", not the binary thing shown
above, and the endpoint is identified by name rather than the IP address
that's in your IOR. The corbaloc reference was
corbaloc::d0701b06.pok.hpc-ng.ibm.com:48049/dname

You need a full IOR, including the codeset information, to be able to
send non-ASCII data.

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

--=_alternative 005B056E86257A7D_=
Content-Type: text/html; charset="US-ASCII"

Thanks, Duncan. Based on your comments,
I think I know what the problem is. Will see if my fix going to fix this
and come back to you.
 
 One related question:
 From Client side, when we create ORB
object, we also have a chance to set up some configs, such as nativeCharCodeSet.
But with your comment, you keep saying that the client codeset is affected
by server IOR. So, if client ORB setting and codeset info it get from server
IOR are not match, what will client follow?
 
 Thanks.
 Jingdong Sun 
InfoSphere Streams Development 
Phone  507 253-5958  (T/L 553-5958)   
jindong at us.ibm.com
 
 
 
 From:      
 Duncan Grisby <duncan at grisby.org>
 To:      
 Jingdong Sun/Rochester/IBM at IBMUS,

 Cc:      
 omniorb-list <omniorb-list at omniorb-support.com>
 Date:      
 09/18/2012 09:05 AM
 Subject:    
   Re: [omniORB]
DATA_CONVERSION problem with omniORB 4.1.4
 
<hr noshade>
 
 
 <tt>On Fri, 2012-09-14 at 16:52 -0500, Jingdong Sun wrote: 
 
> IOR string as below: 
> 14 Sep 2012 17:45:38.403 [9509] INFO :::NAM.StartupDaemon 
> M[dnameserver.cpp:afterActivation:685]  - DN_NAM Service IOR:
 
>    Type ID: IDL:NAM/NameService:1.0 
 
That's not the IOR string. That's a decoded version of it. It's good 
enough though. 
 
[...] 
>     Address:  10.6.24.116:48049 
>    Location:  10.6.24.116:48049...SP..%%..... 
>         Key:  fe 82 a5 53 50 00 00 25 25
00 00 00 00 00 
 
That is not the object reference that the log shows the client 
attempting to use. This shows use of an object set with a corbaloc URI: 
 
omniORB: (0) Creating ref to remote: key<dname> 
target id      : IDL:omg.org/CORBA/Object:1.0 
most derived id: 
omniORB: (0) Invoke '_is_a' on remote: key<dname> 
omniORB: (0) Client attempt to connect to giop:tcp:d0701b06.pok.hpc-ng.ibm.com:48049 
 
The object reference has object key "dname", not the binary thing
shown 
above, and the endpoint is identified by name rather than the IP address 
that's in your IOR. The corbaloc reference was 
corbaloc::d0701b06.pok.hpc-ng.ibm.com:48049/dname 
 
You need a full IOR, including the codeset information, to be able to 
send non-ASCII data. 
 
Duncan. 
 
-- 
-- Duncan Grisby         -- 
 -- duncan at grisby.org     -- 
  -- </tt><a href=http://www.grisby.org/><tt>http://www.grisby.org</tt></a><tt>
-- 
 
 
</tt>
 
--=_alternative 005B056E86257A7D_=--

b***@does.not.exist.com

2012-08-31 11:19:44 UTC

Permalink

14 Sep 2012 17:45:38.403 [9509] INFO :::NAM.StartupDaemon
Type ID: IDL:NAM/NameService:1.0

That's not the IOR string. That's a decoded version of it. It's good
enough though.

[...]

Address: 10.6.24.116:48049
Location: 10.6.24.116:48049...SP..%%.....
Key: fe 82 a5 53 50 00 00 25 25 00 00 00 00 00

That is not the object reference that the log shows the client
attempting to use. This shows use of an object set with a corbaloc URI:

omniORB: (0) Creating ref to remote: key<dname>
target id : IDL:omg.org/CORBA/Object:1.0
most derived id:
omniORB: (0) Invoke '_is_a' on remote: key<dname>
omniORB: (0) Client attempt to connect to
giop:tcp:d0701b06.pok.hpc-ng.ibm.com:48049

The object reference has object key "dname", not the binary thing shown
above, and the endpoint is identified by name rather than the IP address
that's in your IOR. The corbaloc reference was
corbaloc::d0701b06.pok.hpc-ng.ibm.com:48049/dname

You need a full IOR, including the codeset information, to be able to
send non-ASCII data.

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

--=_alternative 0063D57B86257A7F_=
Content-Type: text/html; charset="US-ASCII"

I fixed the problem based on your comments.
 Thanks, Duncan, for your help.
 
 Jingdong Sun 
InfoSphere Streams Development 
Phone  507 253-5958  (T/L 553-5958)   
jindong at us.ibm.com
 
 
 
 From:      
 Jingdong Sun/Rochester/IBM
 To:      
 Duncan Grisby <duncan at grisby.org>,

 Cc:      
 omniorb-list <omniorb-list at omniorb-support.com>
 Date:      
 09/18/2012 11:34 AM
 Subject:    
   Re: [omniORB]
DATA_CONVERSION problem with omniORB 4.1.4
 
<hr noshade>
 
 Thanks, Duncan. Based on your comments,
I think I know what the problem is. Will see if my fix going to fix this
and come back to you.
 
 One related question:
 From Client side, when we create ORB
object, we also have a chance to set up some configs, such as nativeCharCodeSet.
But with your comment, you keep saying that the client codeset is affected
by server IOR. So, if client ORB setting and codeset info it get from server
IOR are not match, what will client follow?
 
 Thanks.
 Jingdong Sun 
InfoSphere Streams Development 
Phone  507 253-5958  (T/L 553-5958)   
jindong at us.ibm.com
 
 
 
 
 From:      
 Duncan Grisby <duncan at grisby.org>
 To:      
 Jingdong Sun/Rochester/IBM at IBMUS,

 Cc:      
 omniorb-list <omniorb-list at omniorb-support.com>
 Date:      
 09/18/2012 09:05 AM
 Subject:    
   Re: [omniORB]
DATA_CONVERSION problem with omniORB 4.1.4
 
<hr noshade>
 
 
 <tt>On Fri, 2012-09-14 at 16:52 -0500, Jingdong Sun wrote: 
 
> IOR string as below: 
> 14 Sep 2012 17:45:38.403 [9509] INFO :::NAM.StartupDaemon 
> M[dnameserver.cpp:afterActivation:685]  - DN_NAM Service IOR:
 
>    Type ID: IDL:NAM/NameService:1.0 
 
That's not the IOR string. That's a decoded version of it. It's good 
enough though. 
 
[...] 
>     Address:  10.6.24.116:48049 
>    Location:  10.6.24.116:48049...SP..%%..... 
>         Key:  fe 82 a5 53 50 00 00 25 25
00 00 00 00 00 
 
That is not the object reference that the log shows the client 
attempting to use. This shows use of an object set with a corbaloc URI: 
 
omniORB: (0) Creating ref to remote: key<dname> 
target id      : IDL:omg.org/CORBA/Object:1.0 
most derived id: 
omniORB: (0) Invoke '_is_a' on remote: key<dname> 
omniORB: (0) Client attempt to connect to giop:tcp:d0701b06.pok.hpc-ng.ibm.com:48049 
 
The object reference has object key "dname", not the binary thing
shown 
above, and the endpoint is identified by name rather than the IP address 
that's in your IOR. The corbaloc reference was 
corbaloc::d0701b06.pok.hpc-ng.ibm.com:48049/dname 
 
You need a full IOR, including the codeset information, to be able to 
send non-ASCII data. 
 
Duncan. 
 
-- 
-- Duncan Grisby         -- 
 -- duncan at grisby.org     -- 
  -- </tt><a href=http://www.grisby.org/><tt>http://www.grisby.org</tt></a><tt>
-- 
 
 
</tt>
 
--=_alternative 0063D57B86257A7F_=--