Printable View
Hello,
Outside of the minimal comments in the adapters.xml (version 5.1.1) configuration file, is there any other guidance when setting the <max_size> and <max_free> values found in the <adapter_set_pool> , <authentication_pool> and <data_adapter_pool> tags?
Thank you,
Bill
Hi Bill, the Server uses different thread pools for different internal tasks, to avoid that, under stress conditions, a single task can become a bottleneck for the whole system.
All the invocations to Adapter methods fall in the "SERVER" pool (see <server_pool_max_size> and <server_pool_max_free> in the main configuration file.
By defining Adapter-related thread pools, you can separate the invocation of Adapter methods on a method and Adapter basis.
This may turn out to be useful if some Adapter methods are known to be slow.
For instance, suppose that notifyUser invokes an external service and may last for many seconds, hence many client connections may be waiting at the same time.
As the Server exposes a synchronous interface to the Metadata Adapter, many threads will be active and waiting for notifyUser to return.
By configuring the "SERVER" thread pool, you can put a limit to the number of threads to be created; obviously, we assume that the limit will not be hit in a normal scenario, but only in problematic conditions.
Under these conditions, upon pool exhaustion, all kinds of requests, including subscriptions to sessions currently active, will be kept waiting for a slot in the pool.
To avoid this, you can setup <authentication_pool> for the Metadata Adapter: with that setting, only the new connections (which need notifyUser) will be kept waiting.
The <max_free> setting is less important; if you set <max_size> very high to manage huge bursts, you may choose to set <max_free> lower, to enforce a "garbage collection" of threads after the burst.
However, setting <max_free> too low means that the Server has to spawn new threads also during phases of normal activity from the clients: a waste.
Similar considerations can be made for all pools, based on the range of tasks specified for each of them in the inline comments.
Note that these ranges of tasks are defined hierarchically.
Also note that the range for the <data_adapter_pool> also includes invocations to the Metadata Adapter related with the handling of subscription requests.