<!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:dc0dd0c9-1f9a-4ddf-be18-e1c29ba89a83@teskor.de">
      <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:19444a9a-ca6c-4632-b2bf-8a67d632ca14@teskor.de">
        <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:omniORB-list@omniorb-support.com">omniORB-list@omniorb-support.com</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>