[omniORB] spurious COMM_FAILURE when using fixed ports

Wed Jan 21 13:11:51 UTC 2026

Hi,

in our application we use callbacks for the client. More and more we have to use fixed ports due to firewall concerns. So the

client is started with e.g. -ORBendPoint giop:tcp:localhost:53234

it registers the callback at a Server which will call the callback when there's data or for a heartbeat. This all works fine for 20 years :-)

Now, with a fixed port, we run into a problem when the client is restarted.

after the client connects, the server tries to send something to the client, but the first call (to the new client!) gets a COMM FAILURE

exception. It looks like this in the log:

omniORB: (199) 2026-01-21 10:04:51.861841: LocateRequest to remote: root/stdPOA<0>
omniORB: (199) 2026-01-21 10:04:51.861868: sendChunk: to giop:tcp:[::1]:53234 45 bytes
omniORB: (199) 2026-01-21 10:04:51.861874:
4749 4f50 0102 0103 2100 0000 0800 0000 GIOP....!.......
0000 0000 1500 0000 ff73 7464 504f 41fe .........stdPOA.
b396 7069 0100 999b 0000 0000 00        ..pi.........
omniORB: (199) 2026-01-21 10:04:51.861953: Reset rope addresses (current address giop:tcp:[::1]:53234)
omniORB: (199) 2026-01-21 10:04:51.861962: Error in network receive (start of message): giop:tcp:[::1]:53234
omniORB: (199) 2026-01-21 10:04:51.861966: throw giopStream::CommFailure from giopStream.cc:857(0,MAYBE,COMM_FAILURE_WaitingForReply)
omniORB: (199) 2026-01-21 10:04:51.862028: Client connection giop:tcp:[::1]:53234 refcount = 0
omniORB: (199) 2026-01-21 10:04:51.862033: Client close connection to giop:tcp:[::1]:53234
omniORB: (199) 2026-01-21 10:04:51.862054: throw COMM_FAILURE from omniObjRef.cc:711 (MAYBE,COMM_FAILURE_WaitingForReply)
omniORB: (199) 2026-01-21 10:04:51.862120: State root/stdPOA<58> (active) -> deactivating
omniORB: (199) 2026-01-21 10:04:51.862126: POA(stdPOA) etherealising object root/stdPOA<58> (deactivating).

The server still seems to maintain the callback connection from the previous client run and gets an error in network receive. The next call then succeeds

as it opens a new connection.

The client has finished with ORB::shutdown and ORB::destroy. After that, I still see

tcp6       0      0 localhost:53234         localhost:36898    FIN_WAIT2   -
tcp6      13      0 localhost:36898         localhost:53234  CLOSE_WAIT  217557/LoginServer

for a while.

I found a mail with

Subject: 	Re: [omniORB] Sporadic CommFailure from giopStream.cc:808(0, MAYBE, COMM_FAILURE_WaitingForReply)
Date: 	Thu, 01 Sep 2016 11:11:56 +0100

in this list, which suggests using the parameter outConScanPeriod. With this I can shorten the time of the CLOSE_WAIT But my question

is, is there a possibility that the connection is immediately closed by the server? I see that the client does a FIN on the connection with tcpdump, whicht is ACKed,

but the server does not do anything (it should send a FIN, too).

When I try the same thing with the call_back example from omniorb, I get the same

$ netstat -ap | grep  53234
(Not all processes could be identified, non-owned process info
  will not be shown, you would have to be root to see it all.)
tcp6       0      0 localhost:54290         localhost:53234  TIME_WAIT   -
tcp6       0      0 localhost:53234         localhost:54278  FIN_WAIT2   -
tcp6      13      0 localhost:54278         localhost:53234  CLOSE_WAIT  238137/./cb_server

BUT, on client restart, the server behaves a little bit differently:

omniORB: (5) 2026-01-21 10:34:09.773578: inputMessage: from giop:tcp:[::1]:53234 12 bytes
omniORB: (5) 2026-01-21 10:34:09.773582:
4749 4f50 0102 0105 0000 0000           GIOP........
omniORB: (5) 2026-01-21 10:34:09.773590: Reset rope addresses (current address giop:tcp:[::1]:53234)
omniORB: (5) 2026-01-21 10:34:09.773595: Orderly connection shutdown: giop:tcp:[::1]:53234
omniORB: (5) 2026-01-21 10:34:09.773599: throw giopStream::CommFailure from giopImpl12.cc:192(1,NO,COMM_FAILURE_WaitingForReply)
omniORB: (5) 2026-01-21 10:34:09.773650: Client connection giop:tcp:[::1]:53234 refcount = 0
omniORB: (5) 2026-01-21 10:34:09.773654: Client close connection to giop:tcp:[::1]:53234
omniORB: (5) 2026-01-21 10:34:09.773668: LocateRequest to remote: root<0>
omniORB: (5) 2026-01-21 10:34:09.773673: Resolve name 'localhost'...
omniORB: (5) 2026-01-21 10:34:09.773822: Name 'localhost' resolved to ::1
omniORB: (5) 2026-01-21 10:34:09.773829: Name 'localhost' resolved to 127.0.0.1
omniORB: (5) 2026-01-21 10:34:09.773841: Client attempt to connect to giop:tcp:[::1]:53234
omniORB: (5) 2026-01-21 10:34:09.773941: Client opened connection to giop:tcp:[::1]:53234
omniORB: (5) 2026-01-21 10:34:09.773945: sendChunk: to giop:tcp:[::1]:53234 38 bytes
omniORB: (5) 2026-01-21 10:34:09.773952:
4749 4f50 0102 0103 1a00 0000 0200 0000 GIOP............
0000 0000 0e00 0000 fe91 9d70 6900 00a4 ...........pi...
d400 0000 0000                          ......
omniORB: (5) 2026-01-21 10:34:09.774420: inputMessage: from giop:tcp:[::1]:53234 20 bytes
omniORB: (5) 2026-01-21 10:34:09.774441:
4749 4f50 0102 0104 0800 0000 0200 0000 GIOP............
0100 0000                               ....
omniORB: (5) 2026-01-21 10:34:09.774463: Send codeset service context: (ISO-8859-1,UTF-16)
omniORB: (5) 2026-01-21 10:34:09.774473: sendChunk: to giop:tcp:[::1]:53234 99 bytes
omniORB: (5) 2026-01-21 10:34:09.774478:
4749 4f50 0102 0100 5700 0000 0400 0000 GIOP....W.......
0300 0000 0000 0000 0e00 0000 fe91 9d70 ...............p
6900 00a4 d400 0000 0000 0000 0a00 0000 i...............
6361 6c6c 5f62 6163 6b00 0000 0100 0000 call_back.......
0100 0000 0c00 0000 0100 0000 0100 0100 ................
0901 0100 0000 0000 0700 0000 4865 6c6c ............Hell
6f21 00                                 o!.

The connection is still there as well, but there no exception is thrown to the caller. Im trying to understand the

code (omniORB 4.3.4) but it is a bit difficult. I'm sure we must be doing something wrong but I can't find it.

Additionally I wonder why the connections linger. The client sends a GIOP::CloseConnection and I would expect the other side to close the connection then as well...

Anyway, it's not a show stopper but it would be nice to be able sort these things out.

Any help is welcome. Regards, Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.omniorb-support.com/pipermail/omniorb-list/attachments/20260121/0e03c423/attachment.htm>