[omniORB] COMM Exception

[Duncan Grisby]

On Wednesday 3 July, Richard Hardgrave wrote:

> > 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.

A solution would be to use omniORB 4.0, since that can be configured
to start using a thread and connection pool when too many connections
turn up. That would allow you to prevent it from hitting the file
descriptor limit.

> > > 	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.

It's not a compile time option, it's a policy you can choose when you
create a POA with create_POA().

> > 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?

Yes. You need to deal with concurrent access with mutexes or whatever
is appropriate.

Cheers,

Duncan.

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