[omniORB] Help needed to interpret COMM_FAILURE

[Wernke zur Borg]

Thanks for your comment.

In our case the problem occurs with messages of max. 10 KBytes. I really
suspect a bad link quality. At least I have no better explanation.

Regards, Wernke


> -----Original Message-----
> From: omniorb-list-bounces at omniorb-support.com 
> [mailto:omniorb-list-bounces at omniorb-support.com] On Behalf 
> Of Renzo Tomaselli
> Sent: 25 November 2005 22:06
> To: Omniorb list
> Subject: Re: [omniORB] Help needed to interpret COMM_FAILURE
> 
> Hi all,
>     this sound interesting. We too had an apparently random problem, 
> appearing as a COMM_FAILURE_MarshalArguments instead.
> This occurs while the involved client manages to send very large 
> messages (e.g. several hundred megabytes) to the server, 
> co-located on 
> the same Win host.
> We initialize maxMsgSize to be 1 gigabyte, but we have never seen 
> MARSHAL_MessageSizeExceedLimitOnClient as a minor, as one 
> would expect 
> in case of overflow failures.
> But from Duncan's answer, it seems that connection might be dropped 
> after overcoming max. message size, thus resulting in a 
> shadowing comm. 
> failure. After looking at sources, I saw that this comm. failure can 
> only come along the chain notifyCommFailure<errorOnSend<Send, then 
> transport stuff.
> What is granted for sure, if we reduce message size a bit then this 
> problem disappears.
> Any comment is highly appreciated.
> Thanks,
> 
> Renzo Tomaselli
> 
> 
> Duncan Grisby wrote:
> 
> >On Friday 25 November, "Wernke zur Borg" wrote:
> >
> >  
> >
> >>>>giopStream::CommFailure from
> >>>>        
> >>>>
> >>giopStream.cc:834(0,NO,COMM_FAILURE_UnMarshalArguments)
> >>
> >>I am trying to interpret the source code at that line but I 
> am not 100% sure
> >>if the exception is thrown due to a timeout or to a remote 
> disconnect. If
> >>this is a timeout condition, I would like to know which 
> config parameter I
> >>can use to increase it. It is known that the line between 
> server and client
> >>may sometimes become unstable, so to avoid these 
> disonnections I would need
> >>to increase the stability with larger timeout values.
> >>    
> >>
> >
> >It's not a timeout. If it was, the exception minor code would be
> >TRANSIENT_CallTimedOut.
> >
> >The COMM_FAILURE means the TCP connection was unexpectedly closed.
> >Possibly the network broke. Another alternative is that the 
> server tried
> >to send something larger than the maximum message size 
> (which is 2MB by
> >default), and therefore dropped the connection. You might learn
> >something by turning traceLevel 25 on on the server.
> >
> >Cheers,
> >
> >Duncan.
> >