Heroku Clojure scheduled tasks versus worker threads

[Jonathon McKitrick]

How would you sum up the differences?  Does the worker thread simply run all the time?  Wouldn't that run up the dyno usage?

[danneu]

Heroku cron jobs and workers are prorated like dynos. They run in their own processes. So does booting into heroku bash or heroku console.

Workers generally consume a queue.

I'm not sure what you mean by "worker thread" though. Workers don't run in a thread, and you can launch plain old threads whenever you want to in your Clojure code. Heroku isn't going to bill you for threads. Perhaps I've misunderstood.

[Jonathon McKitrick]

You are correct, I meant to say 'worker process type' as opposed to 'web process type'.

So, the question then, is what would be the difference between a heroku scheduled command (which I currently am running, wakes up, does some work, etc) and a 'worker process' type?  Does the latter need a job queue set up?  Does it run constantly, checking that queue and consuming work items from it?

[danneu]

As you suspect, the Heroku cron job launches, executes code, and bills you for its time and the 'worker' process, like the 'web' process, runs at all times.

web:    lein run -m myapp.web
worker: lein run -m myapp.worker

I imagine myapp.worker can just be (while true (println "Working")) for all Heroku cares.

[Phil Hagelberg]

On Jun 18, 6:22 am, Jonathon McKitrick <jmckitr...@gmail.com> wrote:
> So, the question then, is what would be the difference between a heroku
> scheduled command (which I currently am running, wakes up, does some work,
> etc) and a 'worker process' type?  Does the latter need a job queue set up?
>  Does it run constantly, checking that queue and consuming work items from
> it?

The reply from danneu is right; but more specifically you should set
up a worker process type if you've got enough work to keep a process
busy full-time or if you need a quicker turnaround time for the work
you're sending it. A scheduled process will be cheaper in terms of
time consumed, so if you're not currently bothered by its limitations
you should probably stick with it. Either a worker or a scheduled
process can use a queue to get its jobs, or it can get it from a DB if
the volume is low.

-Phil