OF-3171: Implement basic rate limiting for new connections (C2S and S2S)#3127
OF-3171: Implement basic rate limiting for new connections (C2S and S2S)#3127guusdk wants to merge 2 commits intoigniterealtime:mainfrom
Conversation
- Introduce NewConnectionLimiterRegistry to track new connections per type. - Add per-group rate limiting: client-to-server (C2S) and server-to-server (S2S). - By default, rate limiting is disabled for both C2S and S2S. - Support dynamic updates via system properties for permits per second, max burst, and enabled flag. - Add optional logging for rejected connections with configurable suppression interval. - Ensure unsupported connection types receive unlimited limiters while still collecting metrics. This lays the foundation for controlling the rate of new connections, without yet exposing admin console configuration or statistics.
Integrate rate-limiting counters into Openfire's Statistics API so they are automatically available via JMX and the Monitoring plugin. This adds real-time, thread-safe statistics for rate limiters used for all connection types (eg: socket_c2s, socket_s2s), tracking accepted and rejected connection attempts. Metrics are incremented on every connection attempt, but reset after rate limit configuration changes. Acceptance ratio is intentionally not exposed. Ratios would be derived from cumulative totals since the last rate-limiter reset, causing them to converge over time and potentially mislead users expecting a time-windowed value. Consumers can derive meaningful ratios themselves from the provided accepted and rejected counters.
|
I've now added exposure of rate-limiting statistics via Statistics API Integrate rate-limiting counters into Openfire's Statistics API so they are automatically available via JMX and the Monitoring plugin. This adds real-time, thread-safe statistics for rate limiters used for all connection types (eg: socket_c2s, socket_s2s), tracking accepted and rejected connection attempts. Metrics are incremented on every connection attempt, but reset after rate limit configuration changes. Acceptance ratio is intentionally not exposed. Ratios would be derived from cumulative totals since the last rate-limiter reset, causing them to converge over time and potentially mislead users expecting a time-windowed value. Consumers can derive meaningful ratios themselves from the provided accepted and rejected counters. |
1 participant
This lays the foundation for controlling the rate of new connections, without yet exposing admin console configuration or statistics.