spurious COMM_FAILURE when using fixed ports
Michael Teske via omniORB-list <[email protected]> Wed, 21 Jan 2026 14:11:51 +0100
| Newsgroups | gmane.comp.corba.omniorb.user |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============8611182090634604515==
Content-Type: multipart/alternative;
boundary="------------wO0lTJs9d6hY7By80KhNU8WR"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------wO0lTJs9d6hY7By80KhNU8WR
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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
--------------wO0lTJs9d6hY7By80KhNU8WR
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p><br>
</p>
<p>in our application we use callbacks for the client. More and more
we have to use fixed ports due to firewall concerns. So the</p>
<p>client is started with e.g. -ORBendPoint giop:tcp:localhost:53234</p>
<p>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 :-)</p>
<p>Now, with a fixed port, we run into a problem when the client is
restarted. </p>
<p>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 </p>
<p>exception. It looks like this in the log:</p>
<p><br>
</p>
<p>omniORB: (199) 2026-01-21 10:04:51.861841: LocateRequest to
remote: root/stdPOA<0><br>
omniORB: (199) 2026-01-21 10:04:51.861868: sendChunk: to
giop:tcp:[::1]:53234 45 bytes<br>
omniORB: (199) 2026-01-21 10:04:51.861874:<br>
4749 4f50 0102 0103 2100 0000 0800 0000 GIOP....!.......<br>
0000 0000 1500 0000 ff73 7464 504f 41fe .........stdPOA.<br>
b396 7069 0100 999b 0000 0000 00 ..pi.........<br>
omniORB: (199) 2026-01-21 10:04:51.861953: Reset rope addresses
(current address giop:tcp:[::1]:53234)<br>
omniORB: (199) 2026-01-21 10:04:51.861962: Error in network
receive (start of message): giop:tcp:[::1]:53234<br>
omniORB: (199) 2026-01-21 10:04:51.861966: throw
giopStream::CommFailure from
giopStream.cc:857(0,MAYBE,COMM_FAILURE_WaitingForReply)<br>
omniORB: (199) 2026-01-21 10:04:51.862028: Client connection
giop:tcp:[::1]:53234 refcount = 0<br>
omniORB: (199) 2026-01-21 10:04:51.862033: Client close connection
to giop:tcp:[::1]:53234<br>
omniORB: (199) 2026-01-21 10:04:51.862054: throw COMM_FAILURE from
omniObjRef.cc:711 (MAYBE,COMM_FAILURE_WaitingForReply)<br>
omniORB: (199) 2026-01-21 10:04:51.862120: State
root/stdPOA<58> (active) -> deactivating<br>
omniORB: (199) 2026-01-21 10:04:51.862126: POA(stdPOA)
etherealising object root/stdPOA<58> (deactivating).<br>
<br>
</p>
<p>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</p>
<p>as it opens a new connection.</p>
<p>The client has finished with ORB::shutdown and ORB::destroy.
After that, I still see</p>
<p>tcp6 0 0 localhost:53234 localhost:36898
FIN_WAIT2 - <br>
tcp6 13 0 localhost:36898 localhost:53234
CLOSE_WAIT 217557/LoginServer <br>
</p>
<p>for a while.</p>
<p>I found a mail with</p>
<table cellpadding="0" cellspacing="0" border="0"
class="moz-email-headers-table">
<tbody>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap">Subject: </th>
<td>Re: [omniORB] Sporadic CommFailure from
giopStream.cc:808(0, MAYBE, COMM_FAILURE_WaitingForReply)</td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap">Date: </th>
<td>Thu, 01 Sep 2016 11:11:56 +0100</td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap"><br>
</th>
</tr>
</tbody>
</table>
<p>in this list, which suggests using the parameter
outConScanPeriod. With this I can shorten the time of the
CLOSE_WAIT But my question</p>
<p>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,</p>
<p>but the server does not do anything (it should send a FIN, too).</p>
<p><br>
</p>
<p>When I try the same thing with the call_back example from
omniorb, I get the same</p>
<p>$ netstat -ap | grep 53234<br>
(Not all processes could be identified, non-owned process info<br>
will not be shown, you would have to be root to see it all.)<br>
tcp6 0 0 localhost:54290 localhost:53234
TIME_WAIT - <br>
tcp6 0 0 localhost:53234 localhost:54278
FIN_WAIT2 - <br>
tcp6 13 0 localhost:54278 localhost:53234
CLOSE_WAIT 238137/./cb_server <br>
</p>
<p><br>
</p>
<p>BUT, on client restart, the server behaves a little bit
differently:</p>
omniORB: (5) 2026-01-21 10:34:09.773578: inputMessage: from
giop:tcp:[::1]:53234 12 bytes<br>
omniORB: (5) 2026-01-21 10:34:09.773582: <br>
4749 4f50 0102 0105 0000 0000 GIOP........<br>
omniORB: (5) 2026-01-21 10:34:09.773590: Reset rope addresses
(current address giop:tcp:[::1]:53234)<br>
omniORB: (5) 2026-01-21 10:34:09.773595: Orderly connection
shutdown: giop:tcp:[::1]:53234<br>
omniORB: (5) 2026-01-21 10:34:09.773599: throw
giopStream::CommFailure from
giopImpl12.cc:192(1,NO,COMM_FAILURE_WaitingForReply)<br>
omniORB: (5) 2026-01-21 10:34:09.773650: Client connection
giop:tcp:[::1]:53234 refcount = 0<br>
omniORB: (5) 2026-01-21 10:34:09.773654: Client close connection to
giop:tcp:[::1]:53234<br>
omniORB: (5) 2026-01-21 10:34:09.773668: LocateRequest to remote:
root<0><br>
omniORB: (5) 2026-01-21 10:34:09.773673: Resolve name 'localhost'...<br>
omniORB: (5) 2026-01-21 10:34:09.773822: Name 'localhost' resolved
to ::1<br>
omniORB: (5) 2026-01-21 10:34:09.773829: Name 'localhost' resolved
to 127.0.0.1<br>
omniORB: (5) 2026-01-21 10:34:09.773841: Client attempt to connect
to giop:tcp:[::1]:53234<br>
omniORB: (5) 2026-01-21 10:34:09.773941: Client opened connection to
giop:tcp:[::1]:53234<br>
omniORB: (5) 2026-01-21 10:34:09.773945: sendChunk: to
giop:tcp:[::1]:53234 38 bytes<br>
omniORB: (5) 2026-01-21 10:34:09.773952: <br>
4749 4f50 0102 0103 1a00 0000 0200 0000 GIOP............<br>
0000 0000 0e00 0000 fe91 9d70 6900 00a4 ...........pi...<br>
d400 0000 0000 ......<br>
omniORB: (5) 2026-01-21 10:34:09.774420: inputMessage: from
giop:tcp:[::1]:53234 20 bytes<br>
omniORB: (5) 2026-01-21 10:34:09.774441: <br>
4749 4f50 0102 0104 0800 0000 0200 0000 GIOP............<br>
0100 0000 ....<br>
omniORB: (5) 2026-01-21 10:34:09.774463: Send codeset service
context: (ISO-8859-1,UTF-16)<br>
omniORB: (5) 2026-01-21 10:34:09.774473: sendChunk: to
giop:tcp:[::1]:53234 99 bytes<br>
omniORB: (5) 2026-01-21 10:34:09.774478: <br>
4749 4f50 0102 0100 5700 0000 0400 0000 GIOP....W.......<br>
0300 0000 0000 0000 0e00 0000 fe91 9d70 ...............p<br>
6900 00a4 d400 0000 0000 0000 0a00 0000 i...............<br>
6361 6c6c 5f62 6163 6b00 0000 0100 0000 call_back.......<br>
0100 0000 0c00 0000 0100 0000 0100 0100 ................<br>
0901 0100 0000 0000 0700 0000 4865 6c6c ............Hell<br>
6f21 00 o!.<br>
<br>
<p>The connection is still there as well, but there no exception is
thrown to the caller. Im trying to understand the</p>
<p>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. </p>
<p><br>
</p>
<p>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...</p>
<p><br>
</p>
<p>Anyway, it's not a show stopper but it would be nice to be able
sort these things out. </p>
<p>Any help is welcome. Regards, Michael</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>
--------------wO0lTJs9d6hY7By80KhNU8WR--
--===============8611182090634604515==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
omniORB-list mailing list
[email protected]
https://www.omniorb-support.com/mailman/listinfo/omniorb-list
--===============8611182090634604515==--