<!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>