A Rails gem that enhances Rack::Timeout with safer service timeouts, dynamic timeouts, and custom error pages.
Slowpoke is a Ruby gem that enhances Rack::Timeout for Rails applications by providing safer recovery mechanisms and greater configurability for request timeouts. It prevents unstable application states after timeout events and offers features like dynamic timeouts and custom error pages. The gem prioritizes application stability and safety in production Rails environments.
Rails developers and DevOps engineers managing production Rails applications who need robust timeout handling to maintain application stability and prevent unclean states after request timeouts.
Developers choose Slowpoke over basic Rack::Timeout because it offers safer recovery by killing processes or threads to avoid unclean states, dynamic timeout configuration based on request properties, and customizable error pages. Its unique selling point is the fine-grained control over timeout behavior, balancing performance and reliability with enhanced safety mechanisms.
Rack::Timeout enhancements for Rails
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Kills processes or threads to prevent unclean application states, addressing a known issue with Rack::Timeout where exceptions can leave the app unstable, as mentioned in the README's safer service timeouts section.
Allows timeout durations to be set dynamically based on request properties like URL paths, enabling fine-grained control for different routes, as shown in the production configuration example.
Provides a customizable public/503.html file for timeout responses, improving user experience, and includes a generator to easily set it up in Rails applications.
Enables subscription to timeout events via ActiveSupport::Notifications, facilitating easy integration with monitoring and reporting systems, as documented in the production setup.
The default behavior kills all threads when any one times out in servers like Puma, which the README admits can have a significant negative effect on throughput and responsiveness.
Setting up conditional timeout handling, such as only killing processes during ActiveRecord timeouts, requires writing custom Ruby blocks and understanding the environment, adding setup complexity beyond basic use.
Inherits any limitations or bugs from Rack::Timeout, and users must refer to its external documentation for underlying details, potentially complicating troubleshooting and integration.