[omniORB] DATA_CONVERSION problem with omniORB 4.1.4

[Jingdong Sun]

Hi, there,

I am using omniORB 4.1.4 for my project.
Recently, when I testing with multi-culture characters (such as Chinese),
I keep hitting a DATA_CONVERSION exception from client side.

I set up both client side and server side with following:
omniORB: nativeCharCodeSet = UTF-8
omniORB: nativeWCharCodeSet = UTF-16 (default)
omniORB: validateUTF8 = 0 (default)

But, when I tried to call my interface and send a char* with multi-bytes
characters, I hit following error (with traceLevel=40):
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:39850. 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:39850

I wonder when I set nativeCharCodeSet to UTF8:
1. How come I hit this error from cs-8bit.cc?
2. Anything I can do to solve this problem?

Thanks.
Jingdong Sun
InfoSphere Streams Development
Phone [phone] (T/L 553-5958)
jindong at us.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20120910/d198cbb0/attachment.html>

[Duncan Grisby]

On Mon, 2012-09-10 at 10:55 -0500, Jingdong Sun wrote:

[...]

Post by Jingdong Sun
omniORB: nativeCharCodeSet = UTF-8
omniORB: nativeWCharCodeSet = UTF-16 (default)
omniORB: validateUTF8 = 0(default)
But, when I tried to call my interface and send a char* with
omniORB: (?) Invoke 'register_entry' on remote: key<dname>
omniORB: (?) throw DATA_CONVERSION from cs-8bit.cc:257
(NO,DATA_CONVERSION_CannotMapChar)

[...]

Post by Jingdong Sun
1. How come I hit this error from cs-8bit.cc?

It is trying to convert your UTF-8 data to an 8 bit code set, probably
ISO-8859-1. If you have indeed set the server to use UTF-8 as its native
code set, the problem is almost certainly that you are using a corbaloc
URI in the client.

In GIOP/IIOP, the code set information for a server lives in the IOR,
and it is required by the CORBA standard that if an IOR has no code set
information, the client must assume that it only understands ISO-8859-1.
A corbaloc URI is treated the same as an IOR with no code set
information. Your client is therefore under the impression that your
server requires ISO-8859-1 and is trying to convert to that.

Post by Jingdong Sun
2. Anything I can do to solve this problem?

Define an IDL method that the client can call that returns an object
reference. It can even return the same object reference it was invoked
upon. That way, the client will exchange its corbaloc reference (that
has no code set information) with a full IOR, and then it will be able
to transfer UTF-8.

Cheers,

Duncan.

[Duncan Grisby]

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.

[Jingdong Sun]

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

[Duncan Grisby]

On Fri, 2012-09-14 at 09:31 -0500, Jingdong Sun wrote:

[...]

From client side, I set traceLevel=40, but could not find more useful

As I said, please post the _complete_ trace of the client from
traceLevel 25. We need to see the startup messages and all the
connection establishment.

Duncan.

[Jingdong Sun]

Here is trace file from client:
I set traceLevel=25 as you requested.

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

IIOP Profile
Version: 1.2
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
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

Thanks.
Jingdong Sun
InfoSphere Streams Development
Phone [phone] (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 11:22 AM
Subject: Re: [omniORB] DATA_CONVERSION problem with omniORB 4.1.4



On Fri, 2012-09-14 at 09:31 -0500, Jingdong Sun wrote:

[...]

From client side, I set traceLevel=40, but could not find more useful

As I said, please post the _complete_ trace of the client from
traceLevel 25. We need to see the startup messages and all the
connection establishment.

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20120914/d12e71ad/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pec.pe0.stdouterr
Type: application/octet-stream
Size: 26488 bytes
Desc: not available
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20120914/d12e71ad/attachment-0001.obj>

[Duncan Grisby]

Post by Jingdong Sun
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.

[...]

Post by Jingdong Sun
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.

[Jingdong Sun]

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:

[Jingdong Sun]

I fixed the problem based on your comments.
Thanks, Duncan, for your help.

Jingdong Sun
InfoSphere Streams Development
Phone [phone] (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


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: