<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
<br>
<br>
Duncan Grisby wrote:<br>
<blockquote type="cite"
cite="mid200310061541.h96FfNk10979@grisby.dyndns.org">
<pre wrap="">On Wednesday 1 October, Serguei Kolos wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Below is the part of the output produced by the listing application with
traceLevel=50.
Does anybody have a clue to this issue?
</pre>
</blockquote>
<pre wrap=""><!---->
[...]
</pre>
<blockquote type="cite">
<pre wrap="">omniORB: LocateRequest to remote:
root/POA[ipc/test][ipc_test_object_0]<ipc.test.object.170>
///////////// 2 - 3 seconds delay: nothing is happening
omniORB: throw giopStream::CommFailure from
giopStream.cc:1061(0,NO,TRANSIENT_ConnectFailed)
</pre>
</blockquote>
<pre wrap=""><!---->
I suspect that it's just that whatever machine it's trying to connect
to is taking a few seconds to respond with a connection failure.
Coincidentally, I checked in a change a while ago that prints out the
address it's trying to connect to, so if you update from CVS, you'll
see extra logging telling you which server it's trying to connect to
when it takes a long time. Alternatively, print out the stringified
IOR of each object reference before you try to call it, and decode the
output with catior.</pre>
</blockquote>
I am sure this is not the case, because all the objects were incarnated in
the same process, so<br>
the client must always try to connect to the same machine.<br>
<blockquote type="cite"
cite="mid200310061541.h96FfNk10979@grisby.dyndns.org">
<pre wrap="">
If that isn't the issue, I can only guess that it's the OS taking time
to clear up the remains of all the failed connections.</pre>
</blockquote>
This sounds like a probable reason. May be somebody knows how to tune up
the OS to avoid such<br>
situations.<br>
<br>
Cheers,<br>
Sergei<br>
</body>
</html>