As explained in the FAQ, "Why do I not get concurrent invocations in a server?", Ice allows you to control the size of the server-side thread pool. The number of threads in the pool determines how many remote invocations can be concurrently serviced by a server.
Ice.ThreadPool.Server.SizeWarn causes a server to log a warning once the number of threads that are in use reaches a specified value. By default, the server logs a warning once this number reaches 80% of the maximum number of threads that can be in the pool. (The maximum number of threads is controlled by the
You may notice that, occasionally, a server logs a warning if there are fewer operations in progress than the limit set by
SizeWarn. The reason is that a thread can be considered "in use" even when it is not executing code in one of your servants. Specifically, the Ice run time considers a thread in use as soon as it realizes that a request has arrived for the server to process; at that point, the Ice run time assigns a thread from the pool that unmarshals the request parameters, locates a servant for the request (either in the Active Servant Map (ASM) or by calling the
locate method of a servant locator), initializes the Current object that is passed to the operation implementation and, finally, calls the corresponding method on the servant.
Similarly, the Ice run time considers a thread in use after the thread returns from the operation implementation. At that point, the thread calls the
finished method of a servant locator, marshals the results of the operation back to the client, and performs a number of other housekeeping tasks before finally returning to the thread pool (at which time the threads is no longer considered in use).
All this means that it is possible for a server to log a warning even if fewer than
SizeWarn threads are currently executing inside your servants.
In general, if you see this warning, this is not an immediate cause for concern. All it means is that the server is running low on idle threads and that, if client activity continues unabated, client requests may stall waiting for a server-side thread to become idle. However, even if that happens, it does not result in an error: the Ice run time simply blocks incoming client requests and dispatches them as soon as a thread becomes available. The only way for clients to see hard errors due to thread starvation in the server is if they set a timeout; in that case, the client will get a timeout exception if no thread becomes available in the server for the duration of the timeout.
If you set
Ice.ThreadPool.Server.SizeWarn to the same value as
Ice.ThreadPool.Server.SizeMax, the server logs a warning whenever an incoming request uses the last remaining thread in the pool.