Skip to content

Commit

Permalink
Protect vs resource leakage
Browse files Browse the repository at this point in the history
Previously, if a semaphore was given a block and then went stale, but
eventually completed it's task, it would add a duplicate of its' token
to the available pool. Additionally, any codebase that only used the
block structure would not self-heal from this state.

Non-block usage would self-heal thanks to the unlock method.
  • Loading branch information
Avemark committed Jun 19, 2018
1 parent 8653045 commit c9e85b3
Show file tree
Hide file tree
Showing 2 changed files with 12 additions and 1 deletion.
2 changes: 1 addition & 1 deletion lib/redis/semaphore.rb
Original file line number Diff line number Diff line change
Expand Up @@ -77,7 +77,7 @@ def lock(timeout = nil)
begin
return_value = yield current_token
ensure
signal(current_token)
signal(current_token) if locked?(current_token)
end
end

Expand Down
11 changes: 11 additions & 0 deletions spec/semaphore_spec.rb
Original file line number Diff line number Diff line change
Expand Up @@ -219,6 +219,17 @@
expect(hyper_aggressive_sem.lock(1)).to eq(false)
expect(hyper_aggressive_sem.lock(1)).not_to eq(false)
end

it "should not add extra resources from stale clients" do
hyper_aggressive_sem = Redis::Semaphore.new(:my_semaphore_2, :redis => @redis, :stale_client_timeout => 0.1)

expect {
multisem.lock do
sleep 0.1
hyper_aggressive_sem.release_stale_locks!
end
}.not_to change(multisem, :available_count)
end
end

describe "redis time" do
Expand Down

0 comments on commit c9e85b3

Please sign in to comment.