redis_queued_locks 0.0.40 → 1.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: b46bd07dab8fc9ce3228eb7bb804569a99dfc8f7f65a1eaf085c3af9061ae09e
-  data.tar.gz: 2c9470b5dd4b41a112c93bb891f33ff68f930dc47fd78a37516540249ded415d
+  metadata.gz: 83f1a77fc07b776195720c2f06a7117baa22ea7f68be06120d3fe7befe26db84
+  data.tar.gz: 4a06cb4f59afb485331513ab01172c2836f07702bd79fdc85c95efaa459a2597
 SHA512:
-  metadata.gz: a7e0740247300cf79385c477a66bc823621888104887de33c3868cf4d06a2087ae6b2ea972e8844fd148e8e3b0da9468cfaf276f68f5d1be7e3b80f72e0c31fe
-  data.tar.gz: d920cda1d4f89da24123df0cf95595c87c21e1e4ed18495765ae0f78c1714af325f94e8e88a7971e4bb10250dde4f392095e8d19f010e9a5f0341d3d3201dc0c
+  metadata.gz: ebae6ceee85253f767b0de53b70a69f00590e91bbcdb6c86860c35a00d736f59593f924eaccb13b593def1f9b504f338f786a2eeb59f9dcd4a596c9d70f2f348
+  data.tar.gz: 5e6e97c4645df750d618c778caccd80fa3eab1491e141b238e5e4c1ed15f59c72871c00f10d38269f33ada195b96ed5b407a62cc52d2543a169b150d2150c770

data/CHANGELOG.md

@@ -1,5 +1,8 @@
 ## [Unreleased]
 
+## [1.0.0] - 2024-04-01
+- First Major Release;
+
 ## [0.0.40] - 2024-04-01
 ### Added
 - `RedisQueuedLocks::Client#clear_dead_requests` implementation;

data/README.md

@@ -1,4 +1,4 @@
-# RedisQueuedLocks · [![Gem Version](https://badge.fury.io/rb/redis_queued_locks.svg)](https://badge.fury.io/rb/redis_queued_locks)
+# RedisQueuedLocks · ![Gem Version](https://img.shields.io/gem/v/redis_queued_locks) ![build](https://github.com/0exp/redis_queued_locks/actions/workflows/build.yml/badge.svg??branch=master)
 
 <a href="https://redis.io/docs/manual/patterns/distributed-locks/">Distributed locks</a> with "lock acquisition queue" capabilities based on the Redis Database.
 
@@ -632,12 +632,12 @@ rql.unlock("your_lock_name")
     - pre-configured in `config[:lock_release_batch_size]`;
   - `:logger` - (optional) `[::Logger,#debug]`
     - custom logger object;
-    - has a preconfigured value in `config[:logger]`;
+    - pre-configured value in `config[:logger]`;
   - `:instrumenter` - (optional) `[#notify]`
     - custom instrumenter object;
-    - has a preconfigured value in `config[:isntrumenter]`;
+    - pre-configured value in `config[:isntrumenter]`;
   - `:instrument` - (optional) `[NilClass,Any]`
-    - custom instrumentation data wich will be passed to the instrumenter's payload with :instrument key;
+    - custom instrumentation data wich will be passed to the instrumenter's payload with `:instrument` key;
 
 - returns:
  - `[Hash<Symbol,Numeric>]` - Format: `{ ok: true, result: Hash<Symbol,Numeric> }`;
@@ -865,15 +865,16 @@ rql.queues_info # or rql.qeuues_info(scan_size: 123)
 
 <sup>\[[back to top](#usage)\]</sup>
 
-In some cases your lock requests may become "dead". It can happen when your processs
-that are enqueeud to the lock queue is failed unexpectedly (for some reason) before the lock acquire moment
-and when no any other process does not need this lock anymore. For this case your lock will be cleared only when any process
-will try to acquire this lock again (cuz lock acquirement triggers the removement of expired requests).
+In some cases your lock requests may become "dead". It means that your lock request lives in lock queue in Redis without
+any processing. It can happen when your processs that are enqueeud to the lock queue is failed unexpectedly (for some reason)
+before the lock acquire moment occurs and when no any other process does not need this lock anymore.
+For this case your lock reuquest will be cleared only when any process will try
+to acquire this lock again (cuz lock acquirement triggers the removement of expired requests).
 
 In order to help with these dead requests you may periodically call `#clear_dead_requests`
-with corresponding `dead_ttl` option, that is pre-configured by default via `config[:dead_request_ttl]`.
+with corresponding `:dead_ttl` option, that is pre-configured by default via `config[:dead_request_ttl]`.
 
-An option is required because of it is no any **fast** way to understand which request
+`:dead_ttl` option is required because of it is no any **fast** and **resource-free** way to understand which request
 is dead now and is it really dead cuz each request queue can host their requests with
 a custom queue ttl for each request differently.
 
@@ -1026,15 +1027,15 @@ Detalized event semantics and payload structure:
 
 <sup>\[[back to top](#table-of-contents)\]</sup>
 
+- **strict redlock algorithm support** (support for many `RedisClient` instances);
 - Semantic Error objects for unexpected Redis errors;
-- better specs with 100% test coverage;
-- per-block-holding-the-lock sidecar `Ractor` and `in progress queue` in RedisDB that will extend
+- better specs with 100% test coverage (total rework);
+- (non-`timed` locks): per-ruby-block-holding-the-lock sidecar `Ractor` and `in progress queue` in RedisDB that will extend
   the acquired lock for long-running blocks of code (that invoked "under" the lock
-  whose ttl may expire before the block execution completes). It only makes sense for non-`timed` locks;
-- lock prioritization;
+  whose ttl may expire before the block execution completes). It makes sense for non-`timed` locks *only*;
+- lock request prioritization;
 - support for LIFO strategy;
-- structured logging (separated docs);
-- GitHub Actions CI;
+- more structured logging (separated docs);
 - `RedisQueuedLocks::Acquier::Try.try_to_lock` - detailed successful result analization;
 - better code stylization (+ some refactorings);
 - statistics with UI;

data/lib/redis_queued_locks/version.rb

@@ -5,6 +5,6 @@ module RedisQueuedLocks
   #
   # @api public
   # @since 0.0.1
-  # @version 0.0.40
-  VERSION = '0.0.40'
+  # @version 1.0.0
+  VERSION = '1.0.0'
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: redis_queued_locks
 version: !ruby/object:Gem::Version
-  version: 0.0.40
+  version: 1.0.0
 platform: ruby
 authors:
 - Rustam Ibragimov
 autorequire:
 bindir: exe
 cert_chain: []
-date: 2024-03-31 00:00:00.000000000 Z
+date: 2024-04-01 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: redis-client