Well, lo and behold, its working -- on the Aspen stack, no less! The
trick was to keep the code block in the controller or model the action
was being called from.
The only thing not working at this point is adding a worker when one
is already running.
heroku.set_workers(ENV['HEROKU_APP'], +1)
I've been told by Heroku Support that we need to migrate to the Bamboo
stack, upgrade our heroku and rest-client gems to the latest, and this
should work. Thanks to this community's help, I should be able to add
or subtract workers with just a few lines of code!
add_heroku_worker
heroku =
Dammit! I pressed the space bar and inadvertently posted before I was
done typing the message! :/
That code block obviously should have and 'end,' so here it is:
end
There, I feel better now.
On Jan 25, 8:06 am, rubynoob mysmilecent...@gmail.com wrote:
I've been told by Heroku Support that
I may misunderstand how workers get charged on heroku, but from what
I've seen at http://docs.heroku.com/background-jobs and
http://docs.heroku.com/delayed-job, workers get charged $0.05/hr each
no matter how many are running, pro-rated to the second. The maximum
workers per account seems to be
You can start up as many workers (or dynos, for that matter) as you
want through the command line. 24 is just how high the slider goes on
the pricing page.
On Jan 21, 7:52 am, rubynoob mysmilecent...@gmail.com wrote:
I may misunderstand how workers get charged on heroku, but from what
I've
@Pedro:
Here's a link to the stack trace:
https://docs.google.com/document/d/1ntWg7PKgyOnSmAVkURW00O5i_LEDFdRscE78NR-cSfg/edit?hl=enauthkey=CMnLv7UB
We're using RestClient gem version 1.4.2 with the Heroku gem version
1.17.8, FWIW.
@Chris: That is good to know. So it sounds like I don't need
Instead of storing the count of active workers as a heroku config
variable, I decided to create a table in our database to store the
value in.
So now I've got the problem narrowed down to the last line in the
method. Here's the block of code I've now got:
add_heroku_worker
heroku
I've done autoscaling of workers
here: https://github.com/phaza/Heroku-Delayed-Job-Autoscale
It's actually more like auto-shutdown of a single workers, but it works well
in our environment.
--
You received this message because you are subscribed to the Google Groups
Heroku group.
To post to
That was a good call, you definitely don't want to store variables in
config vars. Save if for constants (passwords, urls, etc).
It seems like you might be getting an error due to different versions
of RestClient, not sure though. What version are you using? What's the
stack trace for the
Sorry, I forgot to provide some important details. Someday I won't be
so noobish about all this stuff. :)
I'm using Ruby 1.8.6 on Windows XP, Rails 2.3.2, heroku gem 1.15.1,
and delayed_job gem 2.0.5.
I would have tried ddollar's heroku-autoscale, but it's not ready for
production apps, and
Kudos to you if you were really able to do what you were trying to do. It
looks like something really useful and complicated and I didn't think it
would be possible at all in production since there's only so much you can
fine tune about workers in Heroku.
Congrats!
On Wed, Jan 19, 2011 at 10:37
I'm trying a different approach to autoscaling workers in my heroku
app.
I'm using a custom config variable in my heroku config I've labeled
'WORKER_COUNT', which represents how many workers are running
currently. I've also added HEROKU_USERNAME, HEROKU_PASSWORD, and
HEROKU_APP to my heroku
12 matches
Mail list logo
