redis_queued_locks 1.7.0 → 1.8.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: cd303479ce60c268e630d4ad770657cbe0223cffcb9990d31a9bb3de92d80843
-  data.tar.gz: 2a19bfed90da70fa8c49bf069a2acd110d3840eeb78f1f21767416c28e5bc6b7
+  metadata.gz: 7f8dd117ee12f1f598da555d02516bb950a2d9640b075a048612726b7a88a6ad
+  data.tar.gz: c0a5ac4a4dcb6f3b448dc23ffa8d0e0e13a726d50bdd98fc40193704aa6f967d
 SHA512:
-  metadata.gz: 0c2d6c956bfc7227cd45c33c8b983ae759e13bf7149121c272821922d66a4be73b57b344e2042f86d0391acbe92de794013e0a67ce6157b402c6a0ca0a3a1740
-  data.tar.gz: e00ec46afd8e5d8ebef469c0a5d86a026562f8060e8abc95c4f3e89aa9351dc8961fe2d9d181aa4e8203056c74fb4aa8c4043f925b93a5b477c44541eec5ad9f
+  metadata.gz: b35d0ef98da0e1ec2c2368b36064eb0501b45d26aaa1b7204230692a41025583366ce181b85eec09cff2d6fe4e93ec146280db78e08f8cbb232a559b91f6d489
+  data.tar.gz: 4776dd89a7bf1e27476877465faf3240988929efe398090fa4b8b4f604a976a861558e6f606278b91c2c95530be6c5205f8245c887befe92a75d4efde31820dc

data/CHANGELOG.md

@@ -1,8 +1,16 @@
 ## [Unreleased]
 
+## [1.8.0] - 2024-06-13
+### Added
+- A configurable option that enables the adding additional lock/queue data to "Acquirement Timeout"-related error messages for better debugging;
+  - Configurable option is used beacuse of the extra error data requires some additional Redis requests that can be costly for memory/cpu/etc resources;
+- An ability to get the current acquirer id (`RedisQueuedLocks::Client#current_acquirer_id`);
+### Changed
+- Added additional lock information to some exceptions that does not require extra Redis requests;
+
 ## [1.7.0] - 2024-06-12
 ### Added
-- New feature: **Lock Access Strategy**: you can obtain a lock in different ways: `queued` (classic queued FIFO), `random` (get the lock immideatly if lock is free), and soon: `lifo` and `barrier`;
+- New feature: **Lock Access Strategy**: you can obtain a lock in different ways: `queued` (classic queued FIFO), `random` (get the lock immideatly if lock is free):
   - `:queued` is used by default (classic `redis_queued_locks` behavior);
   - `:random`: obtain a lock without checking the positions in the queue => if lock is free to obtain - it will be obtained;
 ### Changed

data/README.md

@@ -34,6 +34,7 @@ Provides flexible invocation flow, parametrized limits (lock request ttl, lock t
   - [locks_info](#locks_info---get-list-of-locks-with-their-info)
   - [queues_info](#queues_info---get-list-of-queues-with-their-info)
   - [clear_dead_requests](#clear_dead_requests)
+  - [current_acquirer_id](#current_acquirer_id)
 - [Lock Access Strategies](#lock-access-strategies)
   - [queued](#lock-access-strategies)
   - [random](#lock-access-strategies)
@@ -157,6 +158,29 @@ clinet = RedisQueuedLocks::Client.new(redis_client) do |config|
   # - should be all blocks of code are timed by default;
   config.is_timed_by_default = false
 
+  # (boolean) (default: false)
+  # - When the lock acquirement try reached the acquirement time limit (:timeout option) the
+  #   `RedisQueuedLocks::LockAcquirementTimeoutError` is raised (when `raise_errors` option
+  #   of the #lock method is set to `true`). The error message contains the lock key name and
+  #   the timeout value).
+  # - <true> option adds the additional details to the error message:
+  #   - current lock queue state (you can see which acquirer blocks your request and
+  #     how much acquirers are in queue);
+  #   - current lock data stored inside (for example: you can check the current acquirer and
+  #     the lock meta state if you store some additional data there);
+  # - Realized as an option because of the additional lock data requires two additional Redis
+  #   queries: (1) get the current lock from redis and (2) fetch the lock queue state;
+  # - These two additional Redis queries has async nature so you can receive
+  #   inconsistent data of the lock and of the lock queue in your error emssage because:
+  #   - required lock can be released after the error moment and before the error message build;
+  #   - required lock can be obtained by other process after the error moment and
+  #     before the error message build;
+  #   - required lock queue can reach a state when the blocking acquirer start to obtain the lock
+  #     and moved from the lock queue after the error moment and before the error message build;
+  # - You should consider the async nature of this error message and should use received data
+  #   from error message correspondingly;
+  config.detailed_acq_timeout_error = false
+
   # (symbol) (default: :queued)
   # - Defines the way in which the lock should be obitained;
   # - By default it is configured to obtain a lock in classic `queued` way:
@@ -316,6 +340,7 @@ end
 - [locks_info](#locks_info---get-list-of-locks-with-their-info)
 - [queues_info](#queues_info---get-list-of-queues-with-their-info)
 - [clear_dead_requests](#clear_dead_requests)
+- [current_acquirer_id](#current_acquirer_id)
 
 ---
 
@@ -348,6 +373,7 @@ def lock(
   access_strategy: config[:default_access_strategy],
   identity: uniq_identity, # (attr_accessor) calculated during client instantiation via config[:uniq_identifier] proc;
   meta: nil,
+  detailed_acq_timeout_error: config[:detailed_acq_timeout_error],
   instrument: nil,
   instrumenter: config[:instrumenter],
   logger: config[:logger],
@@ -433,6 +459,25 @@ def lock(
   - A custom metadata wich will be passed to the lock data in addition to the existing data;
   - Custom metadata can not contain reserved lock data keys (such as `lock_key`, `acq_id`, `ts`, `ini_ttl`, `rem_ttl`);
   - `nil` by default (means "no metadata");
+- `detailed_acq_timeout_error` - (optional) `[Boolean]`
+  - When the lock acquirement try reached the acquirement time limit (:timeout option) the
+    `RedisQueuedLocks::LockAcquirementTimeoutError` is raised (when `raise_errors` option
+    set to `true`). The error message contains the lock key name and the timeout value).
+  - <true> option adds the additional details to the error message:
+    - current lock queue state (you can see which acquirer blocks your request and how much acquirers are in queue);
+    - current lock data stored inside (for example: you can check the current acquirer and the lock meta state if you store some additional data there);
+  - Realized as an option because of the additional lock data requires two additional Redis
+    queries: (1) get the current lock from redis and (2) fetch the lock queue state;
+  - These two additional Redis queries has async nature so you can receive
+    inconsistent data of the lock and of the lock queue in your error emssage because:
+    - required lock can be released after the error moment and before the error message build;
+    - required lock can be obtained by other process after the error moment and
+      before the error message build;
+    - required lock queue can reach a state when the blocking acquirer start to obtain the lock
+      and moved from the lock queue after the error moment and before the error message build;
+  - You should consider the async nature of this error message and should use received data
+    from error message correspondingly;
+  - pre-configred in `config[:detailed_acq_timeout_error]`;
 - `logger` - (optional) `[::Logger,#debug]`
   - Logger object used for loggin internal mutation oeprations and opertioan results / process progress;
   - pre-configured in `config[:logger]` with void logger `RedisQueuedLocks::Logging::VoidLogger`;
@@ -725,6 +770,7 @@ def lock!(
   fail_fast: false,
   identity: uniq_identity,
   meta: nil,
+  detailed_acq_timeout_error: config[:detailed_acq_timeout_error]
   logger: config[:logger],
   log_lock_try: config[:log_lock_try],
   instrument: nil,
@@ -1319,8 +1365,45 @@ rql.clear_dead_requests(dead_ttl: 60 * 60 * 1000) # 1 hour in milliseconds
 
 ---
 
+#### #current_acquirer_id
+
+- get the current acquirer identifier in RQL notation that you can use for debugging purposes during the lock analyzation;
+- acquirer identifier format:
+  ```ruby
+    "rql:acq:#{process_id}/#{thread_id}/#{fiber_id}/#{ractor_id}/#{identity}"
+  ```
+- because of the moment that `#lock`/`#lock!` gives you a possibility to customize `process_id`,
+  `fiber_id`, `thread_id`, `ractor_id` and `unique identity` identifiers the `#current_acquirer_id` method provides this possibility too;
+
+Accepts:
+
+- `process_id:` - (optional) `[Integer,Any]`
+  - `::Process.pid` by default;
+- `thread_id:` - (optional) `[Integer,Any]`;
+  - `::Thread.current.object_id` by default;
+- `fiber_id:` - (optional) `[Integer,Any]`;
+  - `::Fiber.current.object_id` by default;
+- `ractor_id:` - (optional) `[Integer,Any]`;
+  - `::Ractor.current.object_id` by default;
+- `identity:` - (optional) `[String,Any]`;
+  - this value is calculated once during `RedisQueuedLock::Client` instantiation and stored in `@uniq_identity`;
+  - this value can be accessed from `RedisQueuedLock::Client#uniq_identity`;
+  - [Configuration](#configuration) documentation: see `config[:uniq_identifier]`;
+  - [#lock](#lock---obtain-a-lock) method documentation: see `uniq_identifier`;
+
+```ruby
+rql.current_acquirer_id
+
+# =>
+"rql:acq:38529/4500/4520/4360/66093702f24a3129"
+```
+
+---
+
 ## Lock Access Strategies
 
+<sup>\[[back to top](#table-of-contents)\]</sup>
+
 - **this documentation section is in progress**;
 - (little details for a context of the current implementation and feautres):
   - defines the way in which the lock should be obitained;

data/lib/redis_queued_locks/acquier/acquire_lock/with_acq_timeout.rb

@@ -3,29 +3,63 @@
 # @api private
 # @since 1.0.0
 module RedisQueuedLocks::Acquier::AcquireLock::WithAcqTimeout
+  # @param redis [RedisClient]
+  #   Redis connection manager required for additional data extraction for error message.
   # @param timeout [NilClass,Integer]
   #   Time period after which the logic will fail with timeout error.
   # @param lock_key [String]
-  #   Lock name.
+  #   Lock name in RQL notation (rql:lock:some-lock-name).
+  # @param lock_name [String]
+  #   Original lock name passed by the businessl logic (without RQL notaiton parts).
   # @param raise_errors [Boolean]
   #   Raise erros on exceptional cases.
+  # @param detailed_acq_timeout_error [Boolean]
+  #   Add additional error data about lock queue and required lock to the timeout error or not.
   # @option on_timeout [Proc,NilClass]
   #   Callback invoked on Timeout::Error.
   # @return [Any]
   #
   # @api private
   # @since 1.0.0
-  def with_acq_timeout(timeout, lock_key, raise_errors, on_timeout: nil, &block)
+  # @version 1.8.0
+  def with_acq_timeout(
+    redis,
+    timeout,
+    lock_key,
+    lock_name,
+    raise_errors,
+    detailed_acq_timeout_error,
+    on_timeout: nil,
+    &block
+  )
     ::Timeout.timeout(timeout, &block)
   rescue ::Timeout::Error
     on_timeout.call unless on_timeout == nil
 
     if raise_errors
-      raise(
-        RedisQueuedLocks::LockAcquiermentTimeoutError,
-        "Failed to acquire the lock \"#{lock_key}\" " \
-        "for the given timeout (#{timeout} seconds)."
-      )
+      if detailed_acq_timeout_error
+        # TODO: rewrite these invocations to separated inner-AcquireLock-related modules
+        #   in order to remove any dependencies from the other public RQL commands cuz
+        #   all AcquireLock logic elements should be fully independent from others as a core;
+        lock_info = RedisQueuedLocks::Acquier::LockInfo.lock_info(redis, lock_name)
+        queue_info = RedisQueuedLocks::Acquier::QueueInfo.queue_info(redis, lock_name)
+
+        # rubocop:disable Metrics/BlockNesting
+        raise(
+          RedisQueuedLocks::LockAcquiermentTimeoutError,
+          "Failed to acquire the lock \"#{lock_key}\" " \
+          "for the given <#{timeout} seconds> timeout. Details: " \
+          "<Lock Data> => #{lock_info ? lock_info.inspect : '<no_data>'}; " \
+          "<Queue Data> => #{queue_info ? queue_info.inspect : '<no_data>'};"
+        )
+        # rubocop:enable Metrics/BlockNesting
+      else
+        raise(
+          RedisQueuedLocks::LockAcquiermentTimeoutError,
+          "Failed to acquire the lock \"#{lock_key}\" " \
+          "for the given <#{timeout} seconds> timeout."
+        )
+      end
     end
   end
 end

data/lib/redis_queued_locks/acquier/acquire_lock/yield_expire.rb

@@ -25,6 +25,7 @@ module RedisQueuedLocks::Acquier::AcquireLock::YieldExpire
   # @param ttl [Integer,NilClass] Lock's time to live (in ms). Nil means "without timeout".
   # @param queue_ttl [Integer] Lock request lifetime.
   # @param block [Block] Custom logic that should be invoked unter the obtained lock.
+  # @param meta [NilClass,Hash<String|Symbol,Any>] Custom metadata wich is passed to the lock data;
   # @param log_sampled [Boolean] Should the logic be logged or not.
   # @param instr_sampled [Boolean] Should the logic be instrumented or not.
   # @param should_expire [Boolean] Should the lock be expired after the block invocation.
@@ -35,7 +36,7 @@ module RedisQueuedLocks::Acquier::AcquireLock::YieldExpire
   #
   # @api private
   # @since 1.3.0
-  # @version 1.7.0
+  # @version 1.8.0
   # rubocop:disable Metrics/MethodLength
   def yield_expire(
     redis,
@@ -47,6 +48,7 @@ module RedisQueuedLocks::Acquier::AcquireLock::YieldExpire
     ttl_shift,
     ttl,
     queue_ttl,
+    meta,
     log_sampled,
     instr_sampled,
     should_expire,
@@ -62,7 +64,7 @@ module RedisQueuedLocks::Acquier::AcquireLock::YieldExpire
       end
 
       if timed && ttl != nil
-        yield_with_timeout(timeout, lock_key, ttl, &block)
+        yield_with_timeout(timeout, lock_key, ttl, acquier_id, meta, &block)
       else
         yield
       end
@@ -97,18 +99,24 @@ module RedisQueuedLocks::Acquier::AcquireLock::YieldExpire
   # @param timeout [Float]
   # @parma lock_key [String]
   # @param lock_ttl [Integer,NilClass]
+  # @param acquier_id [String]
+  # @param meta [NilClass,Hash<Symbol|String,Any>]
   # @param block [Blcok]
   # @return [Any]
   #
   # @api private
   # @since 1.3.0
-  def yield_with_timeout(timeout, lock_key, lock_ttl, &block)
+  # @version 1.8.0
+  def yield_with_timeout(timeout, lock_key, lock_ttl, acquier_id, meta, &block)
     ::Timeout.timeout(timeout, &block)
   rescue ::Timeout::Error
     raise(
       RedisQueuedLocks::TimedLockTimeoutError,
-      "Passed <timed> block of code exceeded " \
-      "the lock TTL (lock: \"#{lock_key}\", ttl: #{lock_ttl})"
+      "Passed <timed> block of code exceeded the lock TTL " \
+      "(lock: \"#{lock_key}\", " \
+      "ttl: #{lock_ttl}, " \
+      "meta: #{meta ? meta.inspect : '<no-meta>'}, " \
+      "acq_id: \"#{acquier_id}\")"
     )
   end
 end

data/lib/redis_queued_locks/acquier/acquire_lock.rb

@@ -69,6 +69,10 @@ module RedisQueuedLocks::Acquier::AcquireLock
     # @option meta [NilClass,Hash<String|Symbol,Any>]
     #   - A custom metadata wich will be passed to the lock data in addition to the existing data;
     #   - Metadata can not contain reserved lock data keys;
+    # @option detailed_acq_timeout_error [Boolean]
+    #   - Add additional data to the acquirement timeout error such as the current lock queue state
+    #   and the required lock state;
+    #   - See `config[:detailed_acq_timeout_error]` for details;
     # @option logger [::Logger,#debug]
     #   - Logger object used from the configuration layer (see config[:logger]);
     #   - See `RedisQueuedLocks::Logging::VoidLogger` for example;
@@ -143,7 +147,7 @@ module RedisQueuedLocks::Acquier::AcquireLock
     #
     # @api private
     # @since 1.0.0
-    # @version 1.7.0
+    # @version 1.8.0
     def acquire_lock(
       redis,
       lock_name,
@@ -163,6 +167,7 @@ module RedisQueuedLocks::Acquier::AcquireLock
       identity:,
       fail_fast:,
       meta:,
+      detailed_acq_timeout_error:,
       instrument:,
       logger:,
       log_lock_try:,
@@ -246,7 +251,8 @@ module RedisQueuedLocks::Acquier::AcquireLock
 
       acq_dequeue = proc do
         dequeue_from_lock_queue(
-          redis, logger,
+          redis,
+          logger,
           lock_key,
           lock_key_queue,
           queue_ttl,
@@ -263,7 +269,15 @@ module RedisQueuedLocks::Acquier::AcquireLock
       )
 
       # Step 2: try to lock with timeout
-      with_acq_timeout(timeout, lock_key, raise_errors, on_timeout: acq_dequeue) do
+      with_acq_timeout(
+        redis,
+        timeout,
+        lock_key,
+        lock_name,
+        raise_errors,
+        detailed_acq_timeout_error,
+        on_timeout: acq_dequeue
+      ) do
         acq_start_time = ::Process.clock_gettime(::Process::CLOCK_MONOTONIC, :microsecond)
 
         # Step 2.1: cyclically try to obtain the lock
@@ -455,6 +469,7 @@ module RedisQueuedLocks::Acquier::AcquireLock
               ttl_shift,
               ttl,
               queue_ttl,
+              meta,
               log_sampled,
               instr_sampled,
               should_expire, # NOTE: should expire the lock after the block execution

data/lib/redis_queued_locks/client.rb

@@ -14,6 +14,7 @@ class RedisQueuedLocks::Client
     setting :try_to_lock_timeout, 10 # NOTE: in seconds
     setting :default_lock_ttl, 5_000 # NOTE: in milliseconds
     setting :default_queue_ttl, 15 # NOTE: in seconds
+    setting :detailed_acq_timeout_error, false
     setting :lock_release_batch_size, 100
     setting :key_extraction_batch_size, 500
     setting :instrumenter, RedisQueuedLocks::Instrument::VoidNotifier
@@ -37,6 +38,7 @@ class RedisQueuedLocks::Client
     validate('try_to_lock_timeout') { |val| val == nil || (val.is_a?(::Integer) && val >= 0) }
     validate('default_lock_tt', :integer)
     validate('default_queue_ttl', :integer)
+    validate('detailed_acq_timeout_error', :boolean)
     validate('lock_release_batch_size', :integer)
     validate('instrumenter') { |val| RedisQueuedLocks::Instrument.valid_interface?(val) }
     validate('uniq_identifier', :proc)
@@ -95,6 +97,39 @@ class RedisQueuedLocks::Client
     @redis_client = redis_client
   end
 
+  # Retrun the current acquirer identifier.
+  #
+  # @option process_id [Integer,Any] Process identifier.
+  # @option thread_id [Integer,Any] Thread identifier.
+  # @option fiber_id [Integer,Any] Fiber identifier.
+  # @option ractor_id [Integer,Any] Ractor identifier.
+  # @option identity [String] Unique per-process string. See `config[:uniq_identifier]`.
+  # @return [String]
+  #
+  # @see RedisQueuedLocks::Resource.get_process_id
+  # @see RedisQueuedLocks::Resource.get_thread_id
+  # @see RedisQueuedLocks::Resource.get_fiber_id
+  # @see RedisQueuedLocks::Resource.get_ractor_id
+  # @see RedisQueuedLocks::Client#uniq_identity
+  #
+  # @api public
+  # @since 1.8.0
+  def current_acquier_id(
+    process_id: RedisQueuedLocks::Resource.get_process_id,
+    thread_id: RedisQueuedLocks::Resource.get_thread_id,
+    fiber_id: RedisQueuedLocks::Resource.get_fiber_id,
+    ractor_id: RedisQueuedLocks::Resource.get_ractor_id,
+    identity: uniq_identity
+  )
+    RedisQueuedLocks::Resource.acquier_identifier(
+      process_id,
+      thread_id,
+      fiber_id,
+      ractor_id,
+      identity
+    )
+  end
+
   # @param lock_name [String]
   #   Lock name to be obtained.
   # @option ttl [Integer]
@@ -146,6 +181,27 @@ class RedisQueuedLocks::Client
   # @option meta [NilClass,Hash<String|Symbol,Any>]
   #   - A custom metadata wich will be passed to the lock data in addition to the existing data;
   #   - Metadata can not contain reserved lock data keys;
+  # @option detailed_acq_timeout_error [Boolean]
+  #  - When the lock acquirement try reached the acquirement time limit (:timeout option) the
+  #    `RedisQueuedLocks::LockAcquirementTimeoutError` is raised (when `raise_errors` option
+  #    set to `true`). The error message contains the lock key name and the timeout value).
+  #  - <true> option adds the additional details to the error message:
+  #    - current lock queue state (you can see which acquirer blocks your request and
+  #      how much acquirers are in queue);
+  #    - current lock data stored inside (for example: you can check the current acquirer and
+  #      the lock meta state if you store some additional data there);
+  #  - Realized as an option because of the additional lock data requires two additional Redis
+  #    queries: (1) get the current lock from redis and (2) fetch the lock queue state;
+  #  - These two additional Redis queries has async nature so you can receive
+  #    inconsistent data of the lock and of the lock queue in your error emssage because:
+  #    - required lock can be released after the error moment and before the error message build;
+  #    - required lock can be obtained by other process after the error moment and
+  #      before the error message build;
+  #    - required lock queue can reach a state when the blocking acquirer start to obtain the lock
+  #      and moved from the lock queue after the error moment and before the error message build;
+  #  - You should consider the async nature of this error message and should use received data
+  #    from error message correspondingly;
+  #  - pre-configred in `config[:detailed_acq_timeout_error]`;
   # @option logger [::Logger,#debug]
   #   - Logger object used from the configuration layer (see config[:logger]);
   #   - See `RedisQueuedLocks::Logging::VoidLogger` for example;
@@ -206,7 +262,7 @@ class RedisQueuedLocks::Client
   #
   # @api public
   # @since 1.0.0
-  # @version 1.7.0
+  # @version 1.8.0
   # rubocop:disable Metrics/MethodLength
   def lock(
     lock_name,
@@ -223,6 +279,7 @@ class RedisQueuedLocks::Client
     access_strategy: config[:default_access_strategy],
     identity: uniq_identity,
     meta: nil,
+    detailed_acq_timeout_error: config[:detailed_acq_timeout_error],
     logger: config[:logger],
     log_lock_try: config[:log_lock_try],
     instrumenter: config[:instrumenter],
@@ -256,6 +313,7 @@ class RedisQueuedLocks::Client
       conflict_strategy:,
       access_strategy:,
       meta:,
+      detailed_acq_timeout_error:,
       logger:,
       log_lock_try:,
       instrument:,
@@ -274,7 +332,7 @@ class RedisQueuedLocks::Client
   #
   # @api public
   # @since 1.0.0
-  # @version 1.7.0
+  # @version 1.8.0
   # rubocop:disable Metrics/MethodLength
   def lock!(
     lock_name,
@@ -291,6 +349,7 @@ class RedisQueuedLocks::Client
     identity: uniq_identity,
     instrumenter: config[:instrumenter],
     meta: nil,
+    detailed_acq_timeout_error: config[:detailed_acq_timeout_error],
     logger: config[:logger],
     log_lock_try: config[:log_lock_try],
     instrument: nil,
@@ -317,6 +376,7 @@ class RedisQueuedLocks::Client
       logger:,
       log_lock_try:,
       meta:,
+      detailed_acq_timeout_error:,
       instrument:,
       instrumenter:,
       conflict_strategy:,

data/lib/redis_queued_locks/version.rb

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

data/redis_queued_locks.gemspec

@@ -15,21 +15,17 @@ Gem::Specification.new do |spec|
     'capabilities based on the Redis Database.'
 
   spec.description =
-    'Distributed locks with "prioritized lock acquisition queue" capabilities ' \
+    '|> Distributed locks with "prioritized lock acquisition queue" capabilities ' \
     'based on the Redis Database. ' \
-    # ---
-    'Each lock request is put into the request queue ' \
-    "(each lock is hosted by it's own queue separately from other queues) and processed " \
+    '|> Each lock request is put into the request queue ' \
+    '(each lock is hosted by it\'s own queue separately from other queues) and processed ' \
     'in order of their priority (FIFO). ' \
-    # ---
-    'Each lock request lives some period of time (RTTL) ' \
+    '|> Each lock request lives some period of time (RTTL) ' \
     '(with requeue capabilities) which guarantees the request queue will never be stacked. ' \
-    # ---
-    'In addition to the classic `queued` (FIFO) strategy RQL supports ' \
+    '|> In addition to the classic `queued` (FIFO) strategy RQL supports ' \
     '`random` (RANDOM) lock obtaining strategy when any acquirer from the lock queue ' \
     'can obtain the lock regardless the position in the queue. ' \
-    # ---
-    'Provides flexible invocation flow, parametrized limits ' \
+    '|> Provides flexible invocation flow, parametrized limits ' \
     '(lock request ttl, lock ttl, queue ttl, lock attempts limit, fast failing, etc), ' \
     'logging and instrumentation.'
 

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: redis_queued_locks
 version: !ruby/object:Gem::Version
-  version: 1.7.0
+  version: 1.8.0
 platform: ruby
 authors:
 - Rustam Ibragimov
 autorequire:
 bindir: exe
 cert_chain: []
-date: 2024-06-12 00:00:00.000000000 Z
+date: 2024-06-13 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: redis-client
@@ -38,8 +38,16 @@ dependencies:
     - - "~>"
       - !ruby/object:Gem::Version
         version: '0.28'
-description: 'Distributed locks with "prioritized lock acquisition queue" capabilities
-  based on the Redis Database. '
+description: '|> Distributed locks with "prioritized lock acquisition queue" capabilities
+  based on the Redis Database. |> Each lock request is put into the request queue
+  (each lock is hosted by it''s own queue separately from other queues) and processed
+  in order of their priority (FIFO). |> Each lock request lives some period of time
+  (RTTL) (with requeue capabilities) which guarantees the request queue will never
+  be stacked. |> In addition to the classic `queued` (FIFO) strategy RQL supports
+  `random` (RANDOM) lock obtaining strategy when any acquirer from the lock queue
+  can obtain the lock regardless the position in the queue. |> Provides flexible invocation
+  flow, parametrized limits (lock request ttl, lock ttl, queue ttl, lock attempts
+  limit, fast failing, etc), logging and instrumentation.'
 email:
 - iamdaiver@gmail.com
 executables: []
@@ -117,7 +125,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 3.3.7
+rubygems_version: 3.5.1
 signing_key:
 specification_version: 4
 summary: Distributed locks with "prioritized lock acquisition queue" capabilities