Bidirectional POA + callback + wide char data: giopStrand state emptied too early?

Tue Dec 22 22:49:27 GMT 2015

On Fri, 2015-12-04 at 11:10 +0100, Daniel Krügler wrote:

[...]
> I have attached both the omniorb configuration file and the omniorb
> log file (see attachment). To clarify what is going on we embedded
> some additional comment lines each one starting with ## where we try
> to explain what the C++ client code is doing at that point.

Thanks for the log. Sorry for taking a while to look into it, but I have
figured out what is going on. As a note for the future, it's helpful if
you have the traceThreadId parameter set to 1 (which is the default),
meaning that thread ids are included in the log messages. You have it
set to zero, which makes it harder to trace through the logs.

Anyway, having spent a while trying to understand JacORB's behaviour
with codeset service contexts, and how it is different from omniORB's,
it turns out that JacORB behaves just like omniORB, and that is not
where the problem lies. The problem is that the connection being used
for bidirectional calls is not the one we thought it was!

Looking at your trace, we see:

omniORB: 2015-12-04 10:40:08.580000: My addresses are: 
omniORB: 10.49.4.161
...
omniORB:   InitRef = NameService=corbaloc:iiop:1.2 at localhost:683/NameService
...
omniORB: 2015-12-04 10:40:21.993000: Initial reference `NameService' resolved from -ORBInitRef argument / ORB registration.
omniORB: 2015-12-04 10:40:21.993000: Invoke '_is_a' on remote: key<NameService>
omniORB: 2015-12-04 10:40:21.994000: Resolve name 'localhost'...
omniORB: 2015-12-04 10:40:22.037000: Name 'localhost' resolved to ::1
...
omniORB: 2015-12-04 10:40:22.037000: Client attempt to connect to giop:tcp:[::1]:683
omniORB: 2015-12-04 10:40:22.038000: Client opened connection to giop:tcp:[::1]:683
omniORB: 2015-12-04 10:40:22.038000: Client registered bidirectional connection to giop:tcp:[::1]:683
...
omniORB: 2015-12-04 10:40:22.040000: Send bidir IIOP service context: ( 10.49.4.161:52530 )

Here it has opened a connection to localhost port 683, corresponding to
the corbaloc initial reference. Because it is a corbaloc, and not a full
IOR, there is no codeset information for the server, and so it uses the
(CORBA standard required) fallback of ISO-8859-1 for char data and no
setting for wchar data. Notice that it doesn't send a codesets service
context.

After talking to the naming service for a while, it resolves an object
reference from it and opens a new connection to contact the object:

omniORB: 2015-12-04 10:40:41.783000: Client attempt to connect to giop:tcp:10.49.4.161:683
omniORB: 2015-12-04 10:40:41.783000: Client opened connection to giop:tcp:10.49.4.161:683
omniORB: 2015-12-04 10:40:41.783000: Client registered bidirectional connection to giop:tcp:10.49.4.161:683
omniORB: 2015-12-04 10:40:41.783000: Send codeset service context: (UTF-8,UTF-16)
omniORB: 2015-12-04 10:40:41.783000: Send bidir IIOP service context: ( 10.49.4.161:52530 )
omniORB: 2015-12-04 10:40:41.784000: sendChunk: to giop:tcp:10.49.4.161:683 201 bytes

Notice that this connection is to 10.49.4.161, port 683. But actually
that is our address, so it is presumably the same server process as
localhost:683. This object reference came as a full IOR with codeset
information in it, so omniORB does send a codeset service context, and
the underlying connection does have known codeset details.

Now omniORB uses the connection with codeset details and happily
receives UTF-16 wstring data in return...

omniORB: 2015-12-04 10:41:27.616000: Invoke 'registerAutomaticProcessingHandler' on remote: key<2889465728.nupf.connector.cst..connector..processing..NupfConnectorService>
omniORB: 2015-12-04 10:41:27.616000: sendChunk: to giop:tcp:10.49.4.161:683 380 bytes
...
omniORB: 2015-12-04 10:41:27.659000: inputMessage: from giop:tcp:10.49.4.161:683 82 bytes
omniORB: 2015-12-04 10:41:27.659000: 
4749 4f50 0102 0001 0000 0046 0000 0006 GIOP.......F....
0000 0000 0000 0000 0000 0036 006e 0075 ...........6.n.u
0070 0066 002d 0061 0075 0074 006f 006d .p.f.-.a.u.t.o.m
0061 0074 0069 0063 002d 0070 0072 006f .a.t.i.c.-.p.r.o
0063 0065 0073 0073 0069 006e 0067 002d .c.e.s.s.i.n.g.-
0033                                    .3
omniORB: 2015-12-04 10:41:27.659000: Received UTF-16 string with no byte order mark.
omniORB: 2015-12-04 10:41:27.659000: Return 'registerAutomaticProcessingHandler' on remote: key<2889465728.nupf.connector.cst..connector..processing..NupfConnectorService>

Now it goes wrong...

omniORB: 2015-12-04 10:41:29.799000: inputMessage: from giop:tcp:[::1]:683 76 bytes
omniORB: 2015-12-04 10:41:29.799000: 
4749 4f50 0102 0000 0000 0040 0000 0001 GIOP....... at ....
0300 0000 0000 0000 0000 0017 ff42 6964 .............Bid
6972 506f 61fe 785f 6156 0100 e970 0000 irPoa.x_aV...p..
0000 0000 0000 000e 5f6e 6f6e 5f65 7869 ........_non_exi
7374 656e 7400 0000 0000 0000           stent.......
## in codesets.cc  getCodeSetServiceContext (break point)
omniORB: 2015-12-04 10:42:59.153000: Dispatching remote call '_non_existent' to: root/BidirPoa<0> (active)

That is a bidirectional callback, but it is on the localhost connection
that was used to talk to the naming service!  That connection
(correctly) doesn't have any codeset details set. The call to
_non_existent is ok, but then...

omniORB: 2015-12-04 10:44:32.261000: inputMessage: from giop:tcp:[::1]:683 3978 bytes
...
omniORB: 2015-12-04 10:44:32.263000: Dispatching remote call 'processAnalysis' to: root/BidirPoa<0> (active)
omniORB: 2015-12-04 10:44:32.263000: throw BAD_PARAM from cs-UTF-16.cc:184 (NO,BAD_PARAM_WCharTCSNotKnown)

So, at the end of all that, the problem is that omniORB unknowingly has
two connections to the same server process, one with codeset details,
and one without. JacORB is using the "wrong" one, without the codeset
details.

You can probably avoid the problem by changing the InitRef setting to
corbaloc:iiop:localhost:683/NameService without the specification of
GIOP 1.2. That will mean that the initial call to the naming service
will use GIOP 1.0, which doesn't support bidirectional. Then the only
bidir-supporting connection will be the second one, which has correct
codeset details. Alternatively, you could give omniORB a full IOR to the
naming service, rather than the corbaloc URI, so it knows the codeset
details right from the start.

Cheers,

Duncan.

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