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

[Duncan Grisby]

On Fri, 2015-11-27 at 16:47 +0100, Daniel Krügler wrote:

[...]
> It seemed to work until we tested our usual case, that is a call-back
> registered by the OmniOrb client which is invoked by the Java server
> and among the callback function parameters we have wide char data
> (wstring), which is dependent on a proper codeset negotiation. Here we
> consistently run into a BAD_PARAM exception when the callback is
> invoked the by the Java server (This error doesn't happen in the
> unidirectional case).

I tried an omniORB only test based on the omniORB bidir example with a
wstring method added to it, and it worked fine, so it's something to do
with the interaction between omniORB and JacORB.

> 2) After registration of the callback the Java server now switches its
> role and becomes a client by invoking any callback function (it
> doesn't matter which, it could even be the _non_existent function). If
> that happens under bidirectional conditions on the OmniOrb side the
> getCodeSetServiceContext event becomes notified with an giopStrand
> that seems to be basically empty, in particular tcs_selected is false
> and both tcs_c and tcs_w have null values. The also transmitted
> ServiceContextList is now an empty list and we therefore run into the
> fallback block

I'm slightly confused. The getCodeSetServiceContext is invoked on the
server side, to get the service context from the call and apply it. What
you're seeing is not that the giopStrand is empty, but that the service
context on the invocation is empty. If the ServiceContextList that is
transmitted is empty, it's the Java side that has sent it empty. That
said, the GIOP specification isn't very clear about how codesets should
be handled in bidirectional connections, and omniORB doesn't send a
codeset service context at all when doing the callback, because the
connection is already open and already has codesets selected.

[...]
> At this point we have no idea any more what have caused the
> "premature" emptyness of the OmniOrb giopStrand, any ideas/suggestions
> would be very much appreciated.

From what you've said, it sounds as if perhaps the Java side has sent an
empty codeset service context, but that seems a bit unlikely.

Can you run the omniORB side with 

  -ORBtraceLevel 40 -ORBtraceInvocations 1

and send the output?  That will hopefully show more clearly what is
going on.

Duncan.

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