[omniORB] COMM Exception

[Richard Hardgrave]

> From dpg1@grisby.org Wed Jul  3 10:31 CDT 2002
> X-Authentication-Warning: pc1-camc4-0-cust148: dpg1 owned process doing -bs
> To: richard.hardgrave@teradyne.com (Richard Hardgrave)
> cc: omniorb-list@realvnc.com
> Subject: Re: [omniORB] COMM Exception 
> From: Duncan Grisby <duncan@grisby.org>
> Date: Wed, 03 Jul 2002 16:28:08 +0100
> 
> On Wednesday 26 June, Richard Hardgrave wrote:
> 
> > 	The trace output, below, may be a result of another
> > problem happening earlier, but I would like to know just
> > what it is trying to tell me.  I'm particularly curious about
> > the "close socket no. -1" statement.  Is this something that
> > can occur under normal circumstances, or has the system
> > already gone to hell in a handbasket, at that point?
> 
> That is concerning. It's difficult figure out what's going on from the
> trace. The minor 146 in the omniConnectionBroken exception is an errno
> value. What does it mean on your platform?

sys/errno.h:#define	ECONNREFUSED	146	/* Connection refused */

This is a familiar problem because we are still "limping" along with
Solaris 2.5.1.  In that version, fopen() only allows a single process
256 file descriptors, even if the "total" limit is adjusted higher.
But, the process that usually gets into this trouble doesn't access
any CORBA objects.

> 
> > 	The process invoking this servant is multithreaded.
> > All calls to the methods in the servant are going to execute
> > sequentially, right?
> 
> Wrong. Unless you are using a POA with the single thread policy, the

I don't remember using an option like this for the compile.

> servant will have concurrent requests made to it.

Oops! So, let me get this straight. If we have a multi-threaded process,
where each thread is invoking methods in the same servant, we would need
mutual exclusion locks around the code accessing its data structures, right?

> 
> > 	I suppose it wouldn't hurt to upgrade to 3.0.4 ?
> 
> 3.0.5 in fact. I think it's a very good idea to upgrade to that before
> you spend too much time looking into what's going on.

I'll put this in as a highly recommended "to do" for the next release.

Thanks,

Richard

> 
> Cheers,
> 
> Duncan.
> 
> -- 
>  -- Duncan Grisby         --
>   -- duncan@grisby.org     --
>    -- http://www.grisby.org --
>