[omniORB] omniORB not using active connections in some situations?

[Duncan Grisby]

On Monday 27 March, jklein at rockwellcollins.com wrote:

> Hopefully attachments work.. Here's the log..
> 
> (See attached file: LOG.txt)

There's something very strange about that log. Are you sure it's just
from one single process, not two or more processes interleaved?  Or is
it missing some lines?

Looking at thread 4, it does this

omniORB: (4) Creating ref to remote: root<2>
 target id      : IDL:CF/DeviceManager:1.0
 most derived id: IDL:CF/DeviceManager:1.0
omniORB: (4) LocateRequest to remote: root<2>
omniORB: (4) Client attempt to connect to giop:tcp:10.0.26.1:32788
omniORB: (4) Switch rope to use address giop:tcp:192.168.78.22:32788
omniORB: (4) LocateRequest to remote: root<2>
omniORB: (4) Client attempt to connect to giop:tcp:192.168.78.22:32788

omniORB: (4) inputMessage: from giop:tcp:10.26.0.1:32892 252 bytes
omniORB: (4) sendChunk: to giop:tcp:10.26.0.1:32892 24 bytes


I don't understand how it could be receiving a new input message
immediately after it logs that it's trying to connect, since it should
have either logged that it was switching the rope to a new address, or
that it had successfully opened the connection.

Aside from that, I can see plenty of places where it's successfully
doing multiple calls using the same connection, after having tried other
addresses, e.g:

omniORB: (4) Switch rope to use address giop:tcp:10.26.1.1:32788
omniORB: (4) LocateRequest to remote: root<2>
omniORB: (4) Client attempt to connect to giop:tcp:10.26.1.1:32788
omniORB: (4) Client opened connection to giop:tcp:10.26.1.1:32788
omniORB: (4) sendChunk: to giop:tcp:10.26.1.1:32788 38 bytes
omniORB: (4) inputMessage: from giop:tcp:10.26.1.1:32788 20 bytes
omniORB: (4)  send codeset service context: (ISO-8859-1,UTF-16)
omniORB: (4) sendChunk: to giop:tcp:10.26.1.1:32788 104 bytes
omniORB: (4) inputMessage: from giop:tcp:10.26.1.1:32788 93 bytes
omniORB: (4) sendChunk: to giop:tcp:10.26.1.1:32788 68 bytes
omniORB: (4) inputMessage: from giop:tcp:10.26.1.1:32788 250 bytes

There you can see it do three calls in a row, all using the same
address.

I forgot to mention that you should also run with -ORBtraceInvocations 1
to see what methods are being called. Can you do another run like that?

Perhaps the issue is that you are dropping all object references that
relate to that server. In that case, omniORB deletes the rope (it
doesn't drop the network connections until they time out), so next time
you get an object reference for the same server, it no longer knows
which address it should use.

Cheers,

Duncan.

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