[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