possible bug found (was Re: spurious COMM_FAILURE when using fixed ports)
Michael Teske via omniORB-list <[email protected]> Thu, 22 Jan 2026 16:59:48 +0100
| Newsgroups | gmane.comp.corba.omniorb.user |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============6163456909842270835==
Content-Type: multipart/alternative;
boundary="------------x6s88jbf3xvQKN43B1XPb7wx"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------x6s88jbf3xvQKN43B1XPb7wx
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Hi,
with the help of log, gdb and strace I found the difference, it's the timeout setting.
Now it's easy to reproduce with the binaries in examples/call_back.
If you start the server like this:
./cb_server -ORBclientCallTimeOutPeriod 6000 -ORBtraceLevel 40 > ior.txt
and then
IOR=`cat ior.txt`
./cb_client -ORBendPoint giop:tcp:localhost:53234 -ORBtraceLevel 40 $IOR
./cb_client -ORBendPoint giop:tcp:localhost:53234 -ORBtraceLevel 40 $IOR
the second client will receive the (MAYBE,COMM_FAILURE_WaitingForReply) exception always.
This is generated in the server while calling the callback.
The reason is in tcpConnection::Recv in tcpConnection.cc. If there is no timeout set,
it will simply call recv(), which will then read the CloseConnection message from the first client run and rebuild
the connection properly.
Once a timeout is set, it will call poll(), which gets this:
poll([{fd=22, events=POLLIN}], 1, 60000) = 1 ([{fd=22, revents=POLLIN|POLLERR|POLLHUP}])
in this case, it is not tried to recv anything but an error is thrown and propagated. I'll try to do a recv there anyway to
process what's still in the buffer and see if that helps.
Would this be a possible solution or would it be better handled elsewhere?
Greetings,
Michael
On 1/22/26 10:13, Michael Teske via omniORB-list wrote:
>
> 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
>
>
> _______________________________________________
> omniORB-list mailing list
> [email protected]
> https://www.omniorb-support.com/mailman/listinfo/omniorb-list
--------------x6s88jbf3xvQKN43B1XPb7wx
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>with the help of log, gdb and strace I found the difference, it's
the timeout setting.</p>
<p>Now it's easy to reproduce with the binaries in
examples/call_back.</p>
<p>If you start the server like this:</p>
<p>./cb_server -ORBclientCallTimeOutPeriod 6000 -ORBtraceLevel 40
> ior.txt</p>
<p>and then </p>
<p>IOR=`cat ior.txt`</p>
<p>./cb_client -ORBendPoint giop:tcp:localhost:53234 -ORBtraceLevel
40 $IOR<br>
</p>
<p>./cb_client -ORBendPoint giop:tcp:localhost:53234 -ORBtraceLevel
40 $IOR<br>
</p>
<p>the second client will receive the
(MAYBE,COMM_FAILURE_WaitingForReply) exception always. </p>
<p>This is generated in the server while calling the callback.</p>
<p><br>
</p>
<p>The reason is in <span
style="background-color:#f7f7f7;padding:0px 0px 0px 2px;"><span
style="color:#2c2c2c;background-color:#f7f7f7;font-family:"Monospace";font-size:11pt;white-space:pre;"><span
style="color:#000000;background-color:#d4d4d4;font-weight:bold;">tcpConnection</span><span
style="color:#000000;font-weight:bold;">::Recv </span></span></span>in
tcpConnection.cc. If there is no timeout set,</p>
<p>it will simply call recv(), which will then read the
CloseConnection message from the first client run and rebuild</p>
<p>the connection properly.</p>
<p>Once a timeout is set, it will call poll(), which gets this:</p>
<p> poll([{fd=22, events=POLLIN}], 1, 60000) = 1 ([{fd=22,
revents=POLLIN|POLLERR|POLLHUP}])</p>
<p>in this case, it is not tried to recv anything but an error is
thrown and propagated. I'll try to do a recv there anyway to</p>
<p>process what's still in the buffer and see if that helps. </p>
<p>Would this be a possible solution or would it be better handled
elsewhere?</p>
<p><br>
</p>
<p>Greetings,</p>
<p> Michael</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 1/22/26 10:13, Michael Teske via
omniORB-list wrote:<br>
</div>
<blockquote type="cite"
cite="mid:[email protected]">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi,</p>
<p><br>
</p>
<p>now I understand at least the working case from the example.
The client calls <span
style="background-color:#ffffff;padding:0px 0px 0px 2px;"><span
style="color:#000000;background-color:#ffffff;font-family:"Monospace";font-size:11pt;white-space:pre;"><span
style="background-color:#d4d4d4;text-decoration:underline;text-decoration-style:solid;text-decoration-color:#0066cc;color:#0066cc;">sendCloseConnection</span></span></span></p>
<p>from giopServer.cc (because the client is the "server"
(corba-wise) for the callback connection), which is not
trace-logged unfortunately.</p>
<p>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</p>
<p>to the next instance of the client which used the same callback
port, in <span
style="background-color:#ffffff;padding:0px 0px 0px 2px;"><span
style="color:#000000;background-color:#ffffff;font-family:"Monospace";font-size:11pt;white-space:pre;"><span
style="color:#268bd2;background-color:#d4d4d4;">giopImpl12</span>::<span
style="text-decoration:underline;text-decoration-style:solid;text-decoration-color:#0066cc;color:#0066cc;">inputQueueMessage</span></span></span>.</p>
<p>This leads to the already mentioned output from the server:</p>
<p>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) </p>
<p>This is not forwarded to the caller but instead the connection
is re-established as it should be.</p>
What's left is to find out, what happens in our case where we get
<blockquote type="cite"
cite="mid:[email protected]">
<p> 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)</p>
</blockquote>
<p>I'll put some more log in the lib and let you know about what I
found out.</p>
<p>Regards, Michael</p>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
omniORB-list mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="https://www.omniorb-support.com/mailman/listinfo/omniorb-list">https://www.omniorb-support.com/mailman/listinfo/omniorb-list</a>
</pre>
</blockquote>
</body>
</html>
--------------x6s88jbf3xvQKN43B1XPb7wx--
--===============6163456909842270835==
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
--===============6163456909842270835==--