Vaughn Iverson

Hi, you can do that, but it necessarily creates a race condition, right? It seems that you still need to handle the rare case where the job is removed between...

I've been considering for some time to put all of the remaining console.warns under some kind of "debug mode". I don't want to remove them, because they are useful at...

Hi, in that quote from the docs, the instances refer to multiple job-collection **servers**, backed by the same (perhaps replicated) mongoDB. It's a scalability feature. This is almost certainly not...

I'm always open to PRs for documentation improvements... :smile: > So it looks like the job server doesn't perform work, but they can be running in the same process (say...

BTW, you can see an example of spawning concurrent sub workers to exploit a multi-core machine here: https://github.com/vsivsi/meteor-file-job-sample-app/blob/master/sample.coffee#L516-L568 This sample app uses graphicsMagick to create thumbnails for uploaded images. The...

The code is here: https://github.com/vsivsi/meteor-job-collection/blob/master/src/shared.coffee#L458 Only one worker can successfully complete that `update`. It works because single document updates (findAndModify) are atomic in MongoDB.

And even if, somehow, multiple workers thought they got the job, only one would get the final valid `runId`, which would cause any subsequent calls from the other worker(s) on...

I'm not sure what `observe` method you are referring to. There are no observes built into job-collection. Workers get work by asking for it, either by calling `getWork` directly, or...

That's right, but you don't have to implement it that way if you don't want to. You can set your workers up to just periodically poll for work using the...

Hi, thanks for your question. The first thing to point out is that job-collection is not designed to be a "real-time" system, in that all scheduling is "best effort" with...