Should worker.start() create a looped process?

[tshelburne]

My setup is about as simple as it could be, but I can't figure out how to keep a worker process running. I've dug into the source code looking for some kind of keepalive and haven't seen anything, and as far as I can tell, the loop function should be running.

Here is my code:

const queue = new BeanstalkdWorker(config.beanstalkd.host, config.beanstalkd.port),

// ----------------------- WEB APP -----------------------

async function run(project) {
	const job = await queue.spawn(`validation`, project)

	return {id: job.id}
}

export default run

// ----------------------- WORKER -----------------------

const COMMAND = `node ${__filename}`
const IS_WORKER = `${process.argv0} ${process.argv.slice(1).join(` `)}` === COMMAND

if (IS_WORKER) {
	queue.handle(`validation`, project => Promise.resolve(validate(project)))
	queue.start()
}

And here is the output from DEBUG=* node ./validate.js

  beanstalkd-worker:validation Starting watchers +0ms
  beanstalkd connecting to 127.0.0.1:11300 +0ms
  beanstalkd connected to 127.0.0.1:11300 +326ms
  beanstalkd Sent command "watch validation" +11ms
  beanstalkd Sent command "ignore default" +2ms
  beanstalkd-worker:validation Reserving job, timeout: 30000 +341ms

After the "Reserving job" debug output, the process ends. Any suggestions would be great, thanks for your time!

[mickhansen]

It should start making continous requests for reservations

[tshelburne]

That's what I expected - is there anything I'm missing in the code above? It's just about as simple a setup as I can imagine, and the process stops immediately.

[mickhansen]

I'll look into it, it does sound odd. As a workaround you can start a setInterval

[tshelburne]

Ah cool - I tried doing a while (true) and that wasn't friendly. I'll ping you back if that's not working.

[tshelburne]

Ok, can confirm, setInterval(() => g.queue.start(), 1000) keeps it running and does process jobs. I thought maybe it had to do with process on the next tick, so I tried setTimeout with 0, but it failed in the same way as the plain g.queue.start() - it would run for a few seconds and then die with no messaging.

[mickhansen]

You probably don't want to keep calling start, but the setInterval alone (doing nothing) should force node to stay open.

Node is detecting that nothing is pending and closes the app, it shouldn't really happen as the library should be continously polling.

[tshelburne]

Ah, it might be something about how await is handled in Node 8 or something in the async loop. I get what you're saying now.

[evert0n]

@mickhansen @tshelburne did you guys figured out a solution other than setInterval I went using this approach but now it's eating my CPU usage, my worker is running at 100%

[tshelburne]

@evert0n I ended up adding process.stdin.resume() to the bottom of the script as a keepalive. Haven't checked the stats on resource usage though.

[mickhansen]

@evert0n There shouldn't be a way that setInterval would eat your cpu