Re: [tao-users] Limit on number of object references when using -ORBConcurrency thread-per-connection

[Steve Totten]

Hi Andre,

Andre Mostert wrote:

> SYNOPSIS:
> Client programs are obtaining and holding several references to
> the naming service.
>
> After about obtaining 235 references, futher attempts to resolve
> the naming service hangs.
>
> DESCRIPTION:
> Start up naming service, using following command:
> Naming_Service -ORBEndPoint iiop://andre:11004 -m 0
>
> The svc.conf file contains:
> dynamic Advanced_Resource_Factory Service_Object *
> TAO_Strategies:_make_TAO_Advanced_Resource_Factory () "-ORBReactorType
> select_mt"
> static Client_Strategy_Factory "-ORBClientConnectionHandler
> MT"
> static Server_Strategy_Factory "-ORBConcurrency
> thread-per-connection"

<snip/>

> SAMPLE FIX/WORKAROUND:
> Don't use -ORBConcurrency thread-per-connection in the svc.conf
> file for the naming service.

I can't explain why you are only able to support 235 connections to
(and, thereby, threads) in the Naming Service. However, using the
thread-per-connection concurrency strategy with the Naming Service does
not seem very useful. The thread-per-connection concurrency strategy
is not really appropriate for the typical use cases in which the Naming
Service participates. Typically, clients connect to the Naming Service
soon after they start, use it for a small number of operations (e.g., to
bind or resolve a few object references), then never talk to it again
(except perhaps to resolve a new object reference for some sort of
fail-over or re-try scenario). With thread-per-connection, each of
those connections will have a thread dedicated to it in the server, but
those threads will be idle most of the time. The thread's lifespan is
tied to the connection's lifespan. In TAO, the client ORB caches
connections assuming they will be reused, so those connections usually
stay up for the lifespan of the client process. [Note: You may want to
look up information about TAO's connection purging strategies.] The
thread-per-connection strategy is more appropriate when a relatively
small number of clients will connect to a server and use it for several
operations, and when client operations are relatively independent of one
another. As you have seen, the default concurrency strategy (one thread
servicing many client connections) is usually just fine for the Naming
Service.

Steve
--
----------------------------------------------------------------
Steve Totten, Principal Software Engineer and Partner
Object Computing, Inc. (OCI), St. Louis, MO, USA
http://www.ociweb.com/ http://www.theaceorb.com/
----------------------------------------------------------------

[Thomas Lockhart]

>> After about obtaining 235 references, futher attempts to resolve
>> the naming service hangs.

> I can't explain why you are only able to support 235 connections to
> (and, thereby, threads) in the Naming Service. However, using the
> thread-per-connection concurrency strategy with the Naming Service does

> not seem very useful...

Sorry I missed the first part of the thread. But on Linux you get 8MB
per thread in stack space: 8MB*235 gets close to 2GB so maybe you are
approaching your memory space limit?

Set the stack size to much smaller via the shell before starting the
program or check to see if there is a command line option for the naming
service to do that. Relatively light-weight threads seem to get by with
64KB stacks so you may be able to shrink down by orders of magnitude.

hth

- Tom

[Andre Mostert]

Hi Thomas

Turning down the stack size does allow more connections, so it seems you were spot on.  This is on 64-bit though, so I didn't expect that to be a problem.

As Steve also pointed out, mt for naming service is actually unnecessary and wasteful, so I think using a single threaded configuration for that looks like a better solution for us.

Thanks

--Andre