Behrad Zari
Behrad Zari
right @pgte , in the current Kue code we have seen a couple of recovery codes from this situation
A good example of how to provide _priorities_: https://github.com/josiahcarlson/rpqueue/blob/master/rpqueue/__init__.py#L226
I'd planned to start the refactoring to atomic Kue 1.0 early 2015, however it was my very busy days. I'm thinking of starting it in a few months, and remember...
if you have a local redis instance (or one without poor network connection) you won't face queued stuck jobs. however active stuck jobs is something caused 95% by your app...
I've been very busy for a couple of months...
brpoplpush is one of methods of reaching atomicity/consistency but in favor of loosing priorities... I don't want to drop priority queues, and implementing them with brpoplpush adds some complexities. Another...
have you tested v1 branch @rturk ? you should align with your requirements if it fits you the bee-queue @rturk
Thank you @olalonde , I will try to check this ASAP
I think we should lazy load job.data & job.results
`watchStuckJobs` is actually an old workaround method which will be dropped later. However you can create a PR if you want :)