[omniORB] CORBA::TRANSIENT and lag

Duncan Grisby duncan at grisby.org
Wed Aug 28 11:39:07 BST 2013


On Tue, 2013-08-20 at 01:57 +0200, Sylvain Gault wrote:

> > Sometime, when I call a method on a remote object, I get a
> > CORBA::TRANSIENT exception. I've been told that in this case, I should
> > just retry that call.

Whether that's the right thing to do depends on what you're trying to
achieve...

[...]
> Additional information:
> It may not be linked to omniORB directly.
> 
> When running my process within strace, I can see the following lines:
> 
> 01:00:50.668058 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 132
> 01:00:50.668120 setsockopt(132, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> 01:00:50.668195 fcntl(132, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
> 01:00:50.668262 connect(132, {sa_family=AF_INET, sin_port=htons(43193), sin_addr=inet_addr("10.132.0.10")}, 16) = -1 EINPROGRESS (Operation now in progress)
> 01:00:50.668534 poll([{fd=132, events=POLLOUT}], 1, -1) = 1 ([{fd=132, revents=POLLOUT|POLLERR|POLLHUP}])
> 01:01:11.669504 write(2, "omniORB: Failed to connect (no peer name): 10.132.0.10\n", 55) = 55

[...]
> What I understand is that it tries to connect a non blocking socket, and
> 21 seconds later it fails.
> However, the peer node do not see any incoming connection.
> I guess the packets were just dropped because of the trafic shaping...

Yes, it looks like that's what's happening. The delay before the connect
fails is in the TCP stack, not in omniORB.

[...]
> Can I, somehow, shorten the delay between the call start and the
> exception throw?

Look at the omniORB::clientConnectTimeout() function /
clientConnectTimeOutPeriod configuration setting:

http://omniorb.sourceforge.net/omni41/omniORB/omniORB008.html#htoc95


Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --





More information about the omniORB-list mailing list