Changelog for ruby3.3-rubygem-rails_failover-0.8.1-1.43.x86_64.rpm :

* Mon Feb 21 2022 Stephan Kulow updated to version 0.8.1 see installed CHANGELOG.md
* Tue Jan 25 2022 Stephan Kulow updated to version 0.8.0 see installed CHANGELOG.md [#]# [0.8.0] - 2022-01-17 - FEATURE: Compatibility with Rails 7.0+
* Thu Jun 24 2021 Stephan Kulow updated to version 0.7.3 see installed CHANGELOG.md [#]# [0.7.3] - 2021-04-15 - FEATURE: Compatibility with Rails 6.1 [#]# [0.7.2] - 2021-04-14 No changes. [#]# [0.7.1] - 2021-04-14 - FIX: Backward compatability with Rails 6.0 [#]# [0.7.0] - 2021-04-14 - FEATURE: Partial compatibility with Rails 6.1
* Wed Jan 20 2021 Stephan Kulow updated to version 0.6.5 see installed CHANGELOG.md [#]# [0.6.5] - 2020-12-16 - FIX: Catch exceptions that are not intercepted by `ActionDispatch::DebugExceptions`. [#]# [0.6.4] - 2020-12-09 - FIX: Handle the case when the replica is set equal to the primary [#]# [0.6.3] - 2020-12-07 - FIX: Handle clients which are connecting during fallback [#]# [0.6.2] - 2020-11-19 - FIX: Use concurrent-ruby maps to simplify concurrency logic. Resolves a number of possible concurrency issues [#]# [0.6.1] - 2020-11-19 - FIX: Recover correctly if both the primary and replica go offline Previously, a replica failing would cause it to be added to the \'primaries_down\' list. The fallback handler would then continuously try and fallback the replica to itself, looping forever, and meaning that fallback to primary would never happen. [#]# [0.6.0] - 2020-11-09 - FEATURE: Run failover/fallback callbacks once for each backend Previously the failover callback would only fire when the first backend failed, and the fallback callback would only fire when the last backend recovered. Now both failover and fallback callbacks will be triggered for each backend. The key for each backend is also passed to the callbacks for consumption by consuming applications. - FEATURE: Add primaries_down_count function to failover handlers This is intended for consumption by monitoring systems (e.g. the Discourse prometheus exporter) [#]# [0.5.9] - 2020-11-06 - FIX: Ignore errors from the redis socket shutdown call This can fail with various i/o errors, but in all cases we want the thread to continue closing the connection with the error, and all the other connections. [#]# [0.5.8] - 2020-11-05 - FIX: Handle concurrency issues during redis disconnection (#10) This handles concurrency issues which can happen during redis failover/fallback: - Previously, \'subscribed\' redis clients were skipped during the disconnect process. This is resolved by directly accessing the original_client from the ::Redis instance - Trying to acquire the mutex on a subscribed redis client is impossible, so the close operation would never complete. Now we send the shutdown() signal to the thread, then allow up to 1 second for the mutex to be released before we close the socket - Failover is almost always triggered inside a redis client mutex. Failover then has its own mutex, within which we attempted to acquire mutexes for all redis clients. This logic causes a deadlock when multiple clients failover simultaneously. Now, all disconnection is performed by the Redis::Handler failover thread, outside of any other mutexes. To make this safe, the primary/replica state is stored in the connection driver, and disconnect_clients is updated to specifically target primary/replica connections.
* Fri Sep 25 2020 Stephan Kulow updated to version 0.5.7 see installed CHANGELOG.md [#]# [0.5.7] - 2020-09-16 - FIX: Avoid disconnecting Redis connections abruptly. [#]# [0.5.6] - 2020-09-14 - FIX: Iteration and mutation of primaries_down in separate threads (#5) Ruby hashes can\'t be modified whilst they are being iterated over. Here, the primaries_down hash is iterated over to check each previously unavailable primary to see if it is now contactable. However, since this hash can be updated in other threads, this iteration isn\'t safe. To prevent this, a copy of the hash is iterated over instead. The GIL should not be released during a hash dup [1], but let\'s not tie ourselves unnecessarily to current MRI behaviour. [1]: https://github.com/ruby-concurrency/concurrent-ruby/issues/528
* Thu Aug 20 2020 Stasiek Michalski - Initial package