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

[Daniel Krügler]

2015-12-22 23:49 GMT+01:00 Duncan Grisby <duncan at grisby.org>:
> 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.

First I would like to thank you very much personally and also in
behalf of my colleagues
who were involved with trying to understand this problem!

We also needed some time to digest your analysis result, and I wrote
this followup
to ensure that we are all on the same track now.

> 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.

Completely agreed and noted for any future reports from me!

> 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!
[..]
> 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.

As far as I understand, this is indeed a fundamental limitation of
corbaloc URLs, right? I'm asking, because of another
approach that we are now experimenting with, explained below. But if
you are aware of any (portable) idiom that works with
corbaloc URLs but reaches the same effect of retrieving a NameService
instance whose IOR contains full codeset information I
would appreciate any hints how to realize that. At the end of this
reply I will shortly describe an alternative approach that we
are now trying to work with as a workaround for this problem.

> 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.

That indeed seemed to solve the problem! I say "seemed", because we
can confirm that now wide character transmission works
correctly with the correct codeset information but we currently do
still await reports of our testing unit about whether this approach
also solved the connection problems that occurred in the context of
VMs where we hoped that activating bidirectional communication
would resolve them (This second part was the our motivation to try to
get bidirectional communication working, but it was not part of
the problem that I reported with my original posting).

Your result were a bit like a shock to some of us, because we didn't
expect that enforcing a *lower* GIOP version at some part of the
CORBA  interaction would help here, instead we intensively tried to
ensure that we always had GIOP 1.2 activated.

> 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.

Thanks also for this advice, albeit we failed to find a good idiom
based on this without depending on hardcoded IORs. We
could presumably use files to exchange this information, but we felt
that this would introduce a further complexity that we wouldn't
like to introduce at this point.

But based on your analysis results we came to the following third
approach, that we want to present here to get feedback from the
community reading this reflector and if that is positive enough as a
possible inspiration for others:

Since the basic problem was that the Java server did have two
connections, one with and one without codeset information, we
are now testing the following setting:

1) The server registers the IOR of its NameService within that
NameService just as any other service using the NameService API under
the
name "NameService". It does so similarly as for the registration of
any other service object (Nothing "magic" involved here).

2) Both client and server retrieve the NameService no longer via a
corbaloc URL, but instead via a corbaname URL, e.g.

corbaname:iiop:1.2 at localhost:683#NameService

and according to our recent tests this seemed to retrieve a
NameService whose IOR contains the full codeset information. The
reason for this
choice was our interpretation how corbaname works. Before our tests
had been executed, we were not really sure, *how* corbaname
does initially find the NameService. If it would do so via the same
approach as the corbaloc mechanism does when querying

NameService=corbaloc:iiop:{iiop.major}.{iiop.minor}@{host}:{port}/NameService

this wouldn't have helped much, but it seemed that indeed the
NameService of the server (including full codeset information) is
obtained.

Can you confirm or reject whether these effects are required and
therefore this should be a reliable approach to retrieve a name
service
whose IOR contains the full codeset information?

Thanks again for your great help,

- Daniel