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
Batch API #261
Conversation
…job queue. Limited one job running at the same time per queue instead of using a job's counter to limit it.
…pen wwith any job. Implemented test without a silly timeout
…e method in job backend
Conflicts: Makefile package.json
Fixed minor issue when draining the last job, queue is got before cancel the job.
} | ||
|
||
console.log('Exit gracefully'); | ||
process.exit(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just realised about this. Not a big fan of delegating the control of SIGTERM to batch entity.
I would prefer to have app.js knowing about SIGTERM and calling batch.drain() and waiting for the callback to process.exit. Batch shouldn't know about process, IMO.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree! I'm going to move to app.js right away!
…ble from main app module to expose drain mechanism
|
||
var queue = self.jobQueuePool.getQueue(host); | ||
|
||
this.jobCanceller.drain(job_id, function (err) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing that worries me about this approach is having uninterruptible queries.
I mean, I think the logic here is good: we try to cancel the query:
- If we succeed to cancel, we re-enqueue it, mark it as pending, and wait until is consumed again.
- If we fail to cancel, we keep it running and we don't change the status.
However the query might end at some point but the job will be kept as ... running
(?) status.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll need one status more. unknown
to indicate to user that it wasn't possible to know what happened with the job due to cancel his job failed while draining. In this scenario, user will have to review if his job was done successfully or not.
Do you have a better approach?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a better approach. I agree with you on having unknown
for these scenarios as the current alternative 👍
- Short option in mocha - Using batch event emmit to check job status in test
! |
cc/ @rochoa @javisantana