jc.getWork always returned: []

[tilumi]

I have following small sample for testing jc.getWork.It is wired that I always get empty result from getWork. I wonder is there any problem in this sample?

let jobQueue = new JobCollection('jobQueue');
jobQueue.setLogStream(process.stdout);
if (Meteor.isServer) {
  jobQueue.allow({
    admin: true
  });
}
let jobTypes = {
  convertAndInsert: 'convertAndInsert'
};

if (Meteor.isServer) {
  var worker = function (job, cb) {
    job.done();
    return cb();
  };
  new Job(jobQueue, jobTypes.convertAndInsert, {
    file: "XDDD"
  }).delay(0).save();
  console.log(jobQueue.getWork(jobTypes.convertAndInsert));

}

[tilumi]

I found I missed jobQueue.startJobServer();, so close the issue.

[vsivsi]

@tilumi Glad to figured it out.

You may already know this, but jc.getWork() is a pretty low level function. You should check out jc.processJobs() first to see if it satisfies your requirements. jc.processJobs() is built on top of jc.getWork().

[tilumi]

Yeah, at first I use jc.processJobs() and cannot get jobs to run, so I create this simplest program to debug. I think throwing an error indicating this problem when calling jc.processJobs() or jc.getWork() is much better for debugging.

[vsivsi]

Where would the throw happen? It's not a fatal error, and there's nothing to be done to handle it. There simply isn't any work available before the server is started.

The current behavior is by design, allowing a server to be gracefully shutdown and restarted (e.g. to perform maintenance) without all of the (potentially hundreds of) workers also needing to be restarted.

[tilumi]

OK, throwing exceptions may be inappropriate, but I think a mechanism to acknowledge caller that the server is not started is better, since I stuck for hours to figure out why the work is not got.