-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for takeLock & optionally forcing #1033
base: master
Are you sure you want to change the base?
Conversation
rysi3k
commented
Aug 27, 2018
- Fix for call job.lockKey in scripts.js (it is function, but called as property)
- Possibility to take lock without checking key existance
… as property) 2. Possibility to take lock without checking key existance
Thanks for the PR. Could you please motivate why you would like to force taking a lock? it could potentially have a lot of side effects. |
Hello,
In normal implementation, job will be stalled on bull, but on remote server will be continued. I dont want to restart it. Regards |
In the scenario above, I do not get why the job is stalled, you wrote that the supervisor process crashes, but not the remote server processing the job, right? |
Yes, supervisor where bull works crashes. So, there is different |
If the process running bull crashes, the jobs will picked up later by other bull workers, I still do not fully understand your use case :/ |
Hello.
I missed important part. My `process` function is defined as:
1. Start request to remote server
2. Checks every 15s to get result
3. If remote server will return "done", job is done, bull is notified.
So once started job will process independly from bull.
If bull crashes and whole process will start from begining it will also
send `start` request which cause reset job on remote side.
Regards
|
Can you explain the point 4 a bit more? (If processing is in progress, I take lock of job and run standard requests every 15s) |
Here is my simplified code, it could resolve any confusions.
|
I have studied the code above and I do not understand why it is needed, it looks as if you have implemented a similar mechanism of what already exists in bull to handle stalled jobs. A stalled job will be picked up by a idle worker, just remember to have a large enough value in the |
I have different "process" method in normal processing (start + checkStatus) and durign resuming (only checkStatus). |
ok, so your use case is to run a different process function when re-processing a stalled job? |
Hmmm I think yes, it could be called like this |
In that case I think I have a better solution. I think we can add a "status" flag to the job object that is passed to the processor, so depending on the flag you can run one code or another, it should simplify your code a lot, what do you think? |
Your Idea sounds good and should resolve my problems. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |