Saurabh Nanda

@TomMD @mrputty let's solve this then. What're the thoughts on https://github.com/saurabhnanda/odd-jobs/issues/38#issuecomment-648340999 ? Actually, now that I think about this more, neither of the two approaches would prevent "thrashing" of the...

@mrputty thank you for your comment at https://github.com/saurabhnanda/odd-jobs/issues/44#issuecomment-699034092 Are you and @TomMD working on the same problem, or are you talking about two separate, but similar use-cases?

So, here are the problem constraints: 1. Dequeuing the job only to realize that it's rate-limited and re-queuing it again is a wasteful operation and should be avoided as much...

@mrputty @TomMD if it doesn't divulge any proprietary information, would you be able to share on what basis are the jobs being resource-limited? Is it supposed to be something like:...

So, what I didn't realize is that, some users may want to limit concurrency based on _different_ domain tables. I was assuming that either you'd do it on a per-user...

Also, I realized an advantage of having a separate `job_resources` table. It can have the following columns: `id`, `resource_name`, `concurrency_limit`, **and** `current_job_count` `current_job_count` can be kept up-to-date every time a...

> I don't have any kind of benchmark lying around, but I'm happy to contribute to this effort. However, perhaps what I could contribute would be the dequeueing mechanism, rather...

This is a bug. If you plan to raise a PR for this, it might be a good idea to first start with a test-case that fails.

> Because job runners only check the number of attempts on a job after the job fails i.e. throws an exception, long-running jobs which time out will be repeatedly picked...

Ah - I understand now. And thanks for following this through. It's a subtle catch. The problem is with job timeouts that are not caught by `runJobWithTimeout` (that function throws...