FAQ: Max Threads Limit Feature


Forum Sentry uses threads to process transactions entering the gateway. In the most basic sense, a thread within Sentry is required to handle a typical synchronous message transaction from the time the initial request is made until the response is returned to the client. This can be viewed in the System Logs while in debug mode with the initial entry of "document entered the communication layer" to the final entry of "document left communication layer".

  • Default max-threads setting 4096 (Most optimal)
  • CLI command "show max-threads" will display current setting
  • CLI command "system config max-threads" to set threads between 8 to 16384

Although not common, there may be reasons a Sentry admin may want to lower the thread count to avoid impact to a backend service. However, increasing max-threads is not typically recommended. The values can be set from 8 to 16384, although increasing the count does not necessarily benefit performance.


Sentry admins will need to be aware of high thread counts. There are many factors to take into account, but the most likely reason for high consumption of threads would be a slow responding backend system coupled with high traffic. Therefore, it is important to apply effective timeout settings on the Sentry remote policies to avoid hanging threads. To view current thread usage, click the Performance link under the Diagnostics heading in the left nav. The Performance page will show current threads in use along with the max and average thread counts over the past hour or day. See below.





New Feature

Because the threads are shared across all services within the gateway, there may be times a service takes up a large share of threads. A new feature introduced in Version 9.1.159 allows Forum Sentry administrators to set a max thread limit across all content policies (WSDL, XML, REST, JSON, HTML, STS, OAuth) using a percentage. To use the feature, an admin will need to select the Preferences link under the System heading in the left nav as show below. The admin can then enter a percentage they would like to set as a max thread availability across all content policies. To apply the setting click Save.




A few notes about the setting:

  • All current policies default to 100% per policy, meaning they can consume as many threads as defined within the max-thread setting. This setting is essentially what was previously available in Sentry. In other words, the feature is idle at this setting.
  • Any new content policy built in Sentry will default to 50%, which means if the max-threads are set to 4096, the newly built policy will be limited to consuming 2048 threads.
  • When the threshold is met and the policy is taking up as many threads as it is allocated, an HTTP 503 error will be returned to the client for server too busy. Within the response and in the logs the error "Thread limit of 'x' threads reached by 'WSDL Policy: 'Policy Name'" will be displayed.



Please sign in to leave a comment.