This is an experimental servlet which implements the Servlet interface. It acts as an authorized servlet on behalf on another running servlet. This seems not to be a substitute for the running servlet but provides a mirror for the service.
Quality of Service Filter. This filter limits the number of active requests to the number set by the "maxRequests" init parameter (default 10). If more requests are received, they are suspended and placed on priority queues. Priorities are determined by the getPriority(ServletRequest) method and are a value between 0 and the value given by the "maxPriority" init parameter (default 10), with higher values having higher priority.
This filter is ideal to prevent wasting threads waiting for slow/limited resources such as a JDBC connection pool. It avoids the situation where all of a containers thread pool may be consumed blocking on such a slow resource. By limiting the number of active threads, a smaller thread pool may be used as the threads are not wasted waiting. Thus more memory may be available for use by the active threads.
Furthermore, this filter uses a priority when resuming waiting requests. So that if a container is under load, and there are many requests waiting for resources, the getPriority(ServletRequest) method is used, so that more important requests are serviced first. For example, this filter could be deployed with a maxRequest limit slightly smaller than the containers thread pool and a high priority allocated to admin users. Thus regardless of load, admin users would always be able to access the web application.
The maxRequest limit is policed by a Semaphore and the filter will wait a short while attempting to acquire the semaphore. This wait is controlled by the "waitMs" init parameter and allows the expense of a suspend to be avoided if the semaphore is shortly available. If the semaphore cannot be obtained, the request will be suspended for the default suspend period of the container or the valued set as the "suspendMs" init parameter.
This has been replaced by the QoSFilter. Implemented by the Filter interface, the ThrottlingFilter servlet concern is to protect a web application from having to handle an unmanageable load. This accounts when there is a server that holds one application with standardized resource restrictions and with this will be controlled by lowering or limiting the size of the ThreadPool. But when there are several applications in service or a single app having different resource requirements to different URLs, then the ThrottlingFilter comes in and guiding the number of requests being handled by Jetty.