Lock until_and_while_executing not working as expected #613
Comments
|
Update: I couldn't get the expected behaviour with the config below. I don't lose any data but I can't actually schedule jobs and the console doesn't respond until the first one is done. I can record a video I just don't know if is any relevant. class DumbJob < ApplicationSidekiqWorker
sidekiq_options lock: :until_executed,
lock_timeout: 10,
lock_ttl: nil,
lock_limit: 1
def perform
Clogger.log("Sleep start")
sleep(10.seconds)
Clogger.log("Sleep stop")
end
endWe are still testing different options and getting different outcomes every time, even on different projects (aka myapp on sidekiq-uniq-jobs fork). |
|
Sounds like until_executing could be something for you. It isn't as fancy but admittedly until_and_while_executing is not fully there yet in terms of stability. It seems to vary greatly based on factors I haven't been able to isolate yet. For some projects it works great but for projects there are issues. Your examples above is helpful. I will use them to try and replicate something in tests. The problem is that my tests tell me everything is working fine and unless I can find a way to replicate your problem in a test I am at a loss for what to do. The joy and fallacies with multi threading 🙄 |
|
I found a few persistent issues @carolinesalib, could you give #616 a try and see if it helps you? |
|
It is likely, that your problems will at least to some degree go away if you upgrade to https://github.com/mhenrixon/sidekiq-unique-jobs/releases/tag/v7.1.0. I found some very nasty and difficult to find bugs thanks to your detailed reports @carolinesalib |
|
@mhenrixon Oh, that's great news! I'll give it a try today and I'll let you know 🎉 Thank you!! |
|
Just to give you an update, I still have problems with # Job (using myapp on sidekiq-unique-jobs code)
class UntilAndWhileExecuting10Job
include Sidekiq::Worker
sidekiq_options lock: :until_and_while_executing, on_conflict: :log
def perform
SidekiqUniqueJobs.logger.info("jesus")
sleep 20
SidekiqUniqueJobs.logger.info("christ")
end
endFirst time I run the job (and sometimes for some reason I have to rename the job class) it works as expected. Job On the second attempt, job Maybe I need to try different locks but people at the office are not a fan of changing locks on many jobs. Turns out we use this lock a lot. So what I've been doing is trying to understand better what's going on and maybe write a test that reproduces that. |
|
As pointed out in #617, ArturT found a bug. I accidentally inverted the timeout so that 0 means indefinitely instead of not at all like it should be. The bug was fixed in v7.1.1 which might be highly relevant to your scenario. The second job |
|
To achieve what you are after @carolinesalib you'd have to use something like this: # Job (using myapp on sidekiq-unique-jobs code)
class UntilAndWhileExecuting10Job
include Sidekiq::Worker
sidekiq_options lock: :until_and_while_executing, on_conflict: {
client: :log, server: :raise
}
def perform
SidekiqUniqueJobs.logger.info("jesus")
sleep 20
SidekiqUniqueJobs.logger.info("christ")
end
end |
|
@mhenrixon thanks!! I did some testing and I think that would do ❤️ |
Describe the bug
We are upgrading
sidekiq-unique-jobsgem from version5.0.10to7.0.12and I'm having a hard time trying to figure out if the behaviour change on lockuntil_and_while_executingis expected.We have a mutation job that relies on database changes, so we want it to be unique but also not lose any data. Ideally, it would enqueue the first job, the second job (waiting for the first one to finish) and skip all other duplicated jobs.
Expected behavior
Representation of the job on old version + logs:
Current behavior
When we try to enqueue multiple duplicated jobs, only one is executed, and we end up losing data. See example:
I tested different combinations of sidekiq_options +
until_and_while_executinglock and all of them had weird side effects. Sometimes it worked fine on the first attempt but on the second attempt the job didn't get enqueued when there was one in progress. Like on this example:Additional context
Looks like I can get the desired behaviour if I config my job as the following:
Anyway, I'm still curious to understand if there is a bug on
until_and_while_executingor maybe I configured something bad on my end. Let me know if you need more context or to test different scenarios.I appreciate all the work you've been doing on this gem. Thank you so much!
The text was updated successfully, but these errors were encountered: