[omniORB] spurious COMM_FAILURE when using fixed ports

Michael Teske subscribe at teskor.de
Thu Jan 22 09:13:36 UTC 2026


Hi,


now I understand at least the working case from the example. The client calls sendCloseConnection

from giopServer.cc (because the client is the "server" (corba-wise) for the callback connection), which is not trace-logged unfortunately.

The server gets this message but does not process it yet. It will be done later, when it tries to send the next callback on the same connection

to the next instance of the client which used the same callback port, in giopImpl12::inputQueueMessage.

This  leads to the already mentioned output from the server:

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)

This is not forwarded to the caller but instead the connection is re-established as it should be.

What's left is to find out, what happens in our case where we get
>
> 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)
>
I'll put some more log in the lib and let you know about what I found out.

Regards, Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.omniorb-support.com/pipermail/omniorb-list/attachments/20260122/3f85d8a3/attachment.htm>


More information about the omniORB-list mailing list