[omniORB] Connection Threads and Configuration Parameters

[Duncan Grisby]

On Monday 27 November, Pat Pascal wrote:

> We are having a problem getting a few of the omniORB configuration
> parameters to work as we expected (and as indicated in the documentation
> and config file comments). Or it could be we just don't understand how
> the omniORB client connection server threads work.

Have you read chapter 8 of the omniORB manual?  It goes into lots of
detail about how connections and threads are managed in omniORB.

> In our use of omniORB 4.0.7 on RHEL 4, it is our desire to have only 1
> thread per incoming client connection to our server.  So I have set the
> "threadPerConnectionPolicy" configuration parameter to a value of 1,
> as per the following config file comment:

[...]
> I have also set, the "maxServerThreadPerConnection" parameter
> to a value of 1 (although this may not be necessary if the
> "threadPerConnectionPolicy" is set to 1 --> the config comments and
> documentation are not real clear on whether this is actually required
> or if this parameter only applies when using the thread pool).

As explained in section 8.4.1 of the manual, multiple threads can serve
a single connection, even in thread per connection mode, so you should
indeed set maxServerThreadPerConnection to 1.

> We also do not want idle client connections to the server to close
> (we want the above thread to stay running until closed by the client),
> so I set the "inConScanPeriod" parameter to 0 (instead of the default
> 180 seconds), as indicated in the following config file comment:

[...]
> Unfortunately setting this parameter to 0 appears to have no effect,
> since our client connection thread (which was idle for more than 180
> seconds) was closed at 180 seconds anyways. I tried setting the
> parameter to a larger number (e.g. 240 seconds), but the idle client
> connection still closed at 180 seconds.  If I set the parameter to a
> smaller value (e.g. 60 seconds), then the idle connection actually did
> close at the smaller configured value.  From my testing, it appears
> the parameter's value is properly used if it's less than 180 seconds,
> but using a zero value or a value greater than 180, seems to be
> ignored.

The issue is that in GIOP both clients and servers can (and do) choose
to unilaterally close connections at any time if there are no calls in
flight. You have told the server not to close connections, but it can't
do anything to stop clients closing them. Similarly, the server can't do
anything to stop clients opening multiple simultaneous connections,
which will also break your desire to have just one thread per client.

[...]
> You may wonder why I believe the idle connection thread is closing at
> 180 seconds when these parameters are set to 0.  In our server, we are
> obtaining the thread ID in the incoming client connection call, and
> comparing it to the thread IDs for other incoming client connections.
> The thread ID is unique if a new client connects within 180 seconds
> of the previous successful client connection.  However if a new client
> connects after 180 seconds have elapsed since the previous successful
> client connection, the new client has the same thread ID as the previous
> client connection.  In this last case, I am assuming that omniORB has
> closed the previous client connection thread (thinking it was idle and a
> 180 second timeout has expired), and that the new client ends up getting
> a new thread with an ID that has the same value as the previous client's
> connection thread ID.

Why are you looking at the thread id?  If you're using it to identify
clients, it is a risky thing to do, since it doesn't fit with the
semantics of GIOP. If you want to identify clients, it is far better to
allocate some kind of token for each client, and pass it in each call,
either explicitly as a parameter in each operation, or implicitly in a
service context using interceptors.

Cheers,

Duncan.

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