[omniORB] Why both client and server throw send/receive exceptions?

Huang, Ethan

2007-09-06 13:57:13 UTC

Finally, I found the problem might be caused by timeout problem.
I linked the code with omniORB410_vc8_rtd.dll, and trace into the call.
Interestingly, I found ?Send error? always caused by timeout:
File Tcpconnection.cc
int
tcpConnection::Send(void* buf, size_t sz,
unsigned long deadline_secs,
unsigned long deadline_nanosecs)
?
if (deadline_secs || deadline_nanosecs) {
SocketSetTimeOut(deadline_secs,deadline_nanosecs,t);
if (t.tv_sec == 0 && t.tv_usec == 0) {
// Already timeout.
return 0;
}
?
Does anyone have any ideas?
Shall I change some settings of OmniORB to solve the problem?
Thanks!

________________________________________
From: omniorb-list-***@omniorb-support.com [mailto:omniorb-list-***@omniorb-support.com] On Behalf Of Huang, Ethan
Sent: 2007?9?5? 16:08
To: omniorb-***@omniorb-support.com
Subject: [omniORB] Why both client and server throw send/receive exceptions?

Hi all,
I got a strange problem that sometimes the call could succeed while sometimes the call failed.
In the trace, I observed that when failed, both client and server throw send/receive exceptions.
See the trace below (I used OmniORB 4.1):

Client:
******************************************Start to invoke FactoryImpl->New
omniORB: (0) 2007-09-05 15:40:52.384000: Creating ref to local: root<1>
?target id????? : IDL:cyrano.com/ParamList:1.0
?most derived id: IDL:cyrano.com/ParamList:1.0
omniORB: (0) 2007-09-05 15:40:52.384000: LocateRequest to remote: root<1>
omniORB: (0) 2007-09-05 15:40:52.384000: Client attempt to connect to giop:tcp:1
0.239.34.185:2045
omniORB: (0) 2007-09-05 15:40:52.400000: Client opened connection to giop:tcp:10
.239.34.185:2045
omniORB: (0) 2007-09-05 15:40:52.400000: sendChunk: to giop:tcp:10.239.34.185:20
45 38 bytes
omniORB: (0) 2007-09-05 15:40:52.400000: Switch rope to use address giop:tcp:10.
239.34.185:2045
omniORB: (0) 2007-09-05 15:40:52.400000: Error in network send: giop:tcp:10.239.
34.185:2045
omniORB: (0) 2007-09-05 15:40:52.400000: throw giopStream::CommFailure from giop
Stream.cc:1182(0,NO,TRANSIENT_CallTimedout)
omniORB: (0) 2007-09-05 15:40:52.400000: Client connection refcount = 0
omniORB: (0) 2007-09-05 15:40:52.400000: Client close connection to giop:tcp:10.
239.34.185:2045
------------------------------------------------Failed call FactoryImpl->New

Server:
omniORB: (1) 2007-09-05 15:40:52.384000: Server accepted connection from giop:tc
p:10.239.34.185:2055
omniORB: (7) 2007-09-05 15:40:52.384000: AsyncInvoker: thread id = 7 has started
. Total threads = 3
omniORB: (7) 2007-09-05 15:40:52.384000: giopWorker task execute.
omniORB: (7) 2007-09-05 15:40:52.384000: Accepted connection from giop:tcp:10.23
9.34.185:2055 because of this rule: "* unix,ssl,tcp"
omniORB: (7) 2007-09-05 15:40:52.400000: Error in network receive (start of mess
age): giop:tcp:10.239.34.185:2055
omniORB: (7) 2007-09-05 15:40:52.400000: throw giopStream::CommFailure from giop
Stream.cc:874(0,NO,COMM_FAILURE_UnMarshalArguments)
omniORB: (7) 2007-09-05 15:40:52.400000: Server connection refcount = 1
omniORB: (7) 2007-09-05 15:40:52.400000: Server connection refcount = 0
omniORB: (7) 2007-09-05 15:40:52.400000: Server close connection from giop:tcp:1
0.239.34.185:2055
omniORB: (7) 2007-09-05 15:41:02.396000: AsyncInvoker: thread id = 7 has exited.
?Total threads = 3

The Paramerlist_ptr is the function argument passed in the call.
At first, I guessed it might be caused by time out.
However, I checked the configurations: it set clientCallTimeOutPeriod and clientConnectTimeOutPeriod to ?0?, which means block reply.
So who abort the connection, the client or the server? And why the connection failed?
By the way, both my client and server were in the same single box of WinXP, but in the trace I found that it used the rule ?*unix,ssl,tcp?.
Is this the reason? And how could I fix it?
In addition, sometimes I found the error message ?Can not open a new connection?. What does it mean? Is it limited by WinXP or OmniORB settings?
Thanks!

-Ethan