Skip to content

Conversation

dirk
Copy link
Contributor

@dirk dirk commented May 1, 2017

Makes the Sidekiq worker work with both the sidekiq-unique-jobs gem and Sidekiq Enterprise.

Fixes #4.

Copy link

@tiagomjorge tiagomjorge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for taking the time to improve this awesome gem, @dirk! I have only a small suggestion which I'd love to hear your thoughts about.

module Options
def self.included(mod)
if defined?(Sidekiq::Enterprise)
mod.sidekiq_options unique_for: 10.minutes
Copy link

@tiagomjorge tiagomjorge May 1, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These 10.minutes seem quite arbitrary. Wouldn't it be better to have it living in a config somewhere?

# Only allow one job per set of arguments to ever be in the queue
sidekiq_options :unique => :until_executed
# Pulled out into a module so it can be tested.
module Options

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😍

module Options
def self.included(mod)
if defined?(Sidekiq::Enterprise)
mod.sidekiq_options unique_for: 10.minutes

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, those behaviors seem quite different:

until_executed if we are using the sidekiq-unique-jobs gem
VS
for 10 minutes if we are using the sidekiq enterprise gem.

This is one more reason why I believe that this time should live in a config somewhere and be very well documented.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tiagomjorge these behaviors are more similar than the naming implies. The Sidekiq Enterprise implementation would be equivalent to something like until_executed_or_timeout. The lock is released whenever the first of these two is satisfied, which is usually execution.

To make these two effectively the same we can set the unique_for to an arbitrarily long amount of time. 10 minutes might not be long enough for all situations though, so I agree that a documented config would be nice.

@dirk
Copy link
Contributor Author

dirk commented May 1, 2017

Also, those behaviors seem quite different:

until_executed if we are using the sidekiq-unique-jobs gem
VS
for 10 minutes if we are using the sidekiq enterprise gem.

This is one more reason why I believe that this time should live in a config somewhere and be very well documented.

@tiagomjorge: Sounds totally reasonable! Any preferences for how that configuration should be defined/provided?

@tiagomjorge
Copy link

@dirk we could use an initializer, i.e. initializers/async_cache.rb like the other gems use to do, and set 10.minutes by default, internally.

@dirk
Copy link
Contributor Author

dirk commented May 6, 2017

@tiagomjorge: I'll look into that approach! 😄

@taylorlapeyre
Copy link

a wild dirk appears

@dirk
Copy link
Contributor Author

dirk commented May 22, 2018

a wild dirk appears

...and breaks CI. 😂

@dirk
Copy link
Contributor Author

dirk commented Jun 18, 2018

@tiagomjorge, @taylorlapeyre: CI is all happy now. Mind doing another review? 🙃

(I would assign back to Tiago but I don't got no permissions anymore. 🤣)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants