Adapter Thread Pools

Hi,

I am unclear about avoiding thread starvation and starvation in general in a service. Each adapter can have its own thread pool as noted in the docs.

For example, a server is using SSL and thus has
Ice.ThreadPerConnection=1 set for its communicator and has two adapters, "read" and "write" each with Ice.ThreadPerConnection=1 also. The idea is to avoid read requests from starving write requests. All have ThreadPool.Size=3.

What happens if 3 clients are connected to "read" and 5 more are attempting to connect to "read" and then another tries to connect to "write"? From the docs I am lead to believe that the 5 "read" requests will be transparently delayed but will this in any way affect the "write" request?

Thanks.

Hi,

There are several possible scenarios. For example:

• When you configure an adapter to use thread-per-connection, that adapter does not use a thread pool. Furthermore, there are no thread limits placed on that adapter. In other words, the adapter dedicates a thread to each of its endpoints; those threads are responsible for accepting new connections. Each new connection accepted by that adapter also gets its own thread.
  
• In thread pool mode, the behavior depends on whether adapters are using the shared thread pool, or whether each adapter is configured with its own thread pool. If adapters use the shared thread pool, then new connections and new requests on adapter A could delay further processing in adapter B. To mitigate this, you can either configure each adapter with its own thread pool, or you can set a sufficiently-large maximum size on the shared thread pool such that delays are unlikely.

If you're using SSL with Java2 or C#, then you will have to use thread-per-connection (at least for those adapters with SSL endpoints), in which case the thread pool semantics are irrelevant.

Hope that helps.

- Mark

Sorry for the confusion with the ThreadPool.Size, it should not have been there.

If I am understanding this correctly the following is true:
Using Java2 with SSL and thus thread-per-connection (and no AMI/AMD) there is no way to implement a server with a "read" and "write" object adapter where calls to the "read" adapter will never starve out ones to "write". Unbounded thread growth means that once the OS thread per process limit is reached further client connections, be they to "read" or "write" will fail.

That's correct, there is no way to specify an upper limit on the number of threads created in thread-per-connection mode.

Out of curiosity, why do you still use Java2?

Take care,
- Mark

I am not using Java2, I just thought, having read -- and poorly retained -- last year about the SSL threading limitation with Java that it applied to Java 5 and 6. This is not the case then, thread pools and SSL work with Java 5 and 6? If so you just made my day, thanks.

Yes, you can use SSL with thread pools in Java5 and Java6.

Take care,
- Mark