[omniORB] Client hangs while trying to narrow reference specified by corbaloc

[Duncan Grisby]

On Thursday 27 July, "Patrick Hartling" wrote:

[...]
> omniORB: Accepted connection from giop:tcp:192.168.1.183:37986 because
> of this rule: "* bidir,tcp"
> omniORB: inputMessage: from giop:tcp:192.168.1.183:37986 98 bytes
> omniORB:
> 4749 4f50 0100 0100 5600 0000 0000 0000 GIOP....V.......
> 0200 0000 0101 0008 0d00 0000 4a64 6173 ............Jdas
> 496d 6d65 7273 6976 6509 0031 0600 0000 Immersive..1....
> 5f69 735f 6100 018a 0000 0000 2200 0000 _is_a......."...
> 4944 4c3a 6172 632f 496d 6d65 7273 6976 IDL:arc/Immersiv
> 6541 7070 496e 7465 7266 6163 653a 312e eAppInterface:1.
> 3000                                    0.
> omniORB: Scavenger reduce idle count for strand 0xa1c4690 to 35
> [...]
> omniORB: Scavenger reduce idle count for strand 0xa1c4690 to 0
> omniORB: Scavenger close connection from giop:tcp:192.168.1.183:37986
> omniORB: sendCloseConnection: to giop:tcp:192.168.1.183:37986 12 bytes
> omniORB:
> 4749 4f50 0100 0105 0000 0000           GIOP........

This is very strange. It shows the server receiving an _is_a request as
the client tries to confirm the type of the object reference, but then
the server does not do anything at all to service the request. The fact
that it scavenges the connection as idle shows that it does not think
there are any requests in progress on the connection. The call has just
vanished.

Please can you run with additional tracing of -ORBtraceInvocations 1
-ORBtraceThreadId 1. That might narrow it down a bit.

Are you able to attached to the server with a debugger at the time it's
received the _is_a request and is pausing?  If so, it would be helpful
to get a stack backtrace from all the threads running.

Cheers,

Duncan.

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