Not working with meteor-up

[awesomepan]

I used Meteor-up to deploy my app. Meteor-workers not working with it ... Here maybe the problem: https://github.com/arunoda/meteor-up/issues/173 Please help, thanks

[timothyarmes]

I'm also unable to get this project to work on my server, having used mup. Can anyone suggest a fix? I don't even know where to start.

[timothyarmes]

I can confirm that this is an issue with mup stepping down the user. If I configure meteor up to run meteor as directly as the stepped down user then it works, but that's only possible for ports above 100.

[queso]

@ryw or @schnie any thoughts on this?

[timothyarmes]

The only options are:

1. Configure mup to use root for the meteor user
2. Make a custom modification to mup to wait longer before stepping down (once the workers are up)
3. Find another solution altogether

I chose 3 and went with vsivsi:job-collection instead.

[wulfmeister]

Thanks @timothyarmes, will be trying out vsivsi:job-collection.

[queso]

Ouch, rough :)

[ryw]

1. We're not using mup, and don't plan to. Pull-req to make this work w/ mup would be welcome, of course.

2. We'll likely refactor this package in the future to allow it to work with backends other than monq. Or maybe we'll switch to vsivsi:job-collection too if it's a better solution :) Don't think we were aware of it when we built this package out.

[timothyarmes]

Unfortunately I don't think there anything we can do in terms of a pull-req since you don't have the permissions needed to lauch the child process once the users's been stepped down. This isn't your fault, it's just a design incompatibility.

I've no idea if vsivsi:job-collection is a 'better solution' to background processing, but it's working well for me and it's compatible with mup :)

[ryw]

Yeah I noticed it has a long README which is usually a good sign :)

[queso]

From the looks of the README, you have to run meteor-jobs NPM package and your own node process to get the workers out of the single threaded environment with job-collection?

[timothyarmes]

Update: actually, the code below won't get the workers out of the single threaded environment. My concern with the readme was that it seemed that you had to have a separate app to handle the tasks, whereas that's not actually necessary.

---

Yes, that what it looks like at first. It's off-putting, isn't it ? :)

Turns out, though, that if you read the docs in more detail then there's no need to do that. The read me needs a server-side example IMO. Here's my server-side code (not a separate app, just part of /server) to process emails in the background:

emailJobs = JobCollection 'emailJobQueue'
emailJobs.startJobs()

emailJobs.processJobs 'sendTextEmail', (job, cb) ->
   email = job.data

   try
      Email.send
         to: email.to,
         subject: email.subject,
         text: email.message

      job.done()

   catch e
      job.fail 'Unable to send email'

   finally 
      cb()

and to send them:

  job = emailJobs.createJob 'sendTextEmail',
     to: to
     subject: subject
     message: message

  job.priority 'normal'
     .retry
        retries: 5
        wait: 5 * 60 * 1000 # 15 minutes between attempts
     .save()    

Read the section on processJobs for more info.

[rhyslbw]

Also check out the discussion here for running the workers in a different Meteor app

https://github.com/vsivsi/meteor-job-collection/issues/59

[vsivsi]

BTW, I'll happily accept PRs with documentation improvements for job-collection. :smile: