[omniORB] How to achieve per ORB/thread client connection timeouts

[Duncan Grisby]

On Tue, 2026-07-07 at 15:17 +0200, Thomas Braun via omniORB-list wrote:


[...]
> And I forgot to ask for server tuning knobs. From the 4.5 Server side
> options [1] we currently set [2]
> 
> {"maxServerThreadPoolSize", "100"},
> {"threadPerConnectionUpperLimit", "55"},
> {"threadPerConnectionLowerLimit", "50"},
> .
> 
> My hunch would be that the thread pool size upper limit 
> (maxServerThreadPoolSize) should be larger or?

How to set these various parameters depends a lot on your expected
usage patterns, in particular

- how many different concurrent clients you expect

- how many threads each of those clients has

- how many total concurrent incoming calls you expect / wish to have

  - related to that, whether processing of incoming calls is largely
CPU or I/O bound


By default, omniORB uses thread-per-connection mode, meaning that each
incoming network connection has a dedicated thread. That is the most
efficient scheme, because servicing an incoming call does not require
any thread switching at all — the dedicated thread is blocked on data
arriving on the connection; when data arrives the same thread reads the
request data, performs the call, sends the result data, and goes back
to blocking.

By default, also, if an omniORB client tries to make multiple
concurrent calls to the same server, the client opens multiple network
connections, and so the server gets multiple dedicated threads. That
means the only multiplexing is happening within the OS network stacks,
and they have to be doing that job anyway. Both client and server
processes are able to do all their work with no thread switching
overheads.


Instead of having one thread per connection in the server, omniORB can
instead use a thread pool, meaning that any number of connections are
watched by a single thread in a call to poll() or select(). When data
arrives on a connection, a thread is taken from the pool to service the
request. If you have a very large number of connections, that means you
can have far fewer threads than you would have in thread-per-connection
mode, but it means that every call involves a switch from the poll()
thread to the pool thread, so it has slightly higher overhead.

It is only really worth the thread switching overhead of thread pool
mode if there is a good reason for keeping the number of threads small.
Modern systems usually do not have a problem with having thousands of
threads, so there is often no particular benefit to using a thread
pool. In the days that 32 bit systems were common, there were quite
small limits on the number of threads due to limited virtual address
space for thread stacks, but that is much less of an issue in most
systems today.


The parameters you mention allow omniORB to pick dynamically between
thread-per-connection and thread pool.

{"maxServerThreadPoolSize", "100"},
{"threadPerConnectionUpperLimit", "55"},
{"threadPerConnectionLowerLimit", "50"},

This means that by default, omniORB will be in thread-per-connection
mode. The first 55 connections will get a dedicated thread. Connection
number 56 will cause it to switch into thread pool mode — it will not
get its own thread, but will instead use the pool of up to 100 threads
(the pool is dynamically created and resized, so it does not create 100
threads immediately, rather starts them on demand, up to a maximum of
100).

Perhaps another 200 connections come along. No more per-connection
threads will be created, and those 201 connections share the pool of up
to 100 threads. But perhaps most of the connections are idle a lot of
the time, so maybe the pool only grows to 20 threads because that is
the largest number of concurrent requests.

The original 55 connections still have their dedicated threads, though.
As those connections close, the threads finish, and because there is
still a large number of connections, all new and existing connections
are managed in thread pool mode.

Now, if the total number of connections falls below 50, thread-per-
connection mode is re-enabled. Now new incoming connections are given a
dedicated thread again, until the total connections goes above 55
again.


So, I can't really answer the question of what good numbers might be
for you. If you need a thread pool, having a maximum pool size of 100
is probably fine. Certainly if the server is mostly CPU bound, there is
no benefit to having significantly more threads than there are CPUs
available. On the other hand, if the server is I/O bound, it can be a
very good thing to allow it to have a large number of threads, so more
things can be blocked waiting.


Having said all that, the majority of servers will probably be totally
fine just using the default thread-per-connection mode all the time.


I hope that made sense.

Duncan.

-- 
Duncan Grisby <duncan at grisby.org>