[omniORB] Question about ORB configuration

[Thomas Zumbiehl]

The threadPerConnectionPolicy is set to default value (I'm using omniORB 4.0.7, so it is 1).
For the concurrent calls, let's say it is up to 100. I took 200 to be sure that I'm under the limit.

When the process's blocked, it's for ever.

The "process is blocked" part of the problem seems to be solved by changing the code.

Now, I'm really interrested in the best configuration to tune my servers A and B for managing concurrent requests.

Cheers,

Thomas Zumbiehl
Chef de Projet Développement
BV Associates
http://www.bvassociates.fr

-----Message d'origine-----
De : Duncan Grisby [mailto:duncan at grisby.org] 
Envoyé : vendredi 12 décembre 2008 17:59
À : Thomas Zumbiehl
Cc : omniorb-list at omniorb-support.com
Objet : Re: [omniORB] Question about ORB configuration 

On Friday 12 December, "Thomas Zumbiehl" wrote:

> The latest configuration I got on both A and B servers is :
> scanGranularity=5
> 
> clientTransportRule=* tcp,bidir
> offerBiDirectionalGIOP=1
> oneCallPerConnection=0
> maxGIOPConnectionPerServer=200
> outConScanPeriod=600
> 
> endPoint=giop:tcp::0
> serverTransportRule=* tcp,bidir
> acceptBiDirectionalGIOP=1
> maxServerThreadPerConnection=200
> maxServerThreadPoolSize=200
> inConScanPeriod=600
> 
> Do you think this is correct ?

It's generally a good idea to set outConScanPeriod to be smaller than inConScanPeriod so that clients usually close connections. When servers close connections, clients can end up having to retry calls due to the connection closures.

What is the setting of threadPerConnectionPolicy ?   How many concurrent
calls do you have relative to the setting of 200 for the thread pool size?

What happens when the processes become "blocked"?  Do they recover after a while, or stay blocked for ever?  If they're blocked forever, try attaching with a debugger and get a stack trace for all the threads.

If it's only temporary, you can get more information by running both ends with traceLevel 25 traceThreadId 1 traceTime 1. That will output a lot of debugging information that will hopefully show where the hold-up is.

Cheers,

Duncan.

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