Re: creating a virtual file
Take a look how you can hook File calls. https://github.com/pirj/distributed-shelf If you figure out the file is read orr written, you can fetch/update your DB, or redis as suggested. On Jan 24, 11:37 pm, bluewave shai.sayfanalt...@googlemail.com wrote: I have an application I want to use (http://www.flashxml.net/galleries/ ) this application needs to update an xml file with all the images information in it. if I would be working on disk based system I would just update this file so the web browser can read it. because I am using Heroku I can not update this file in the OS. do you know if I could use send_data to send this xml file instead of using the file on the OS? if you now how to do this please share this with me. Thanks -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
upload local gem files
hi, guys. please let me know how to upload my app to heroku.. I'm tring to upload my rails app but I'm facing an error saying Could not find gem_file in any of the resources. In fact, I use a gem file not listed on http://rubygems.org/. Does Heroku only allow us to upload gem files ( Gemfile ) of http://rubygems.org/? Can I use my gem fileof local enviornment? Thanks in advance -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: My (flawed?) attempt to add or subtract workers via Heroku API.
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 = Heroku::Client.new(ENV['HEROKU_USERNAME'], ENV['HEROKU_PASSWORD']) heroku.set_workers(ENV['HEROKU_APP'], +1) Thanks, everyone! Jim On Jan 21, 10:07 am, rubynoob mysmilecent...@gmail.com wrote: @Pedro: Here's a link to the stack trace:https://docs.google.com/document/d/1ntWg7PKgyOnSmAVkURW00O5i_LEDFdRsc... 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 to introduce a lag as Keenan suggests. Thanks, Jim On Jan 21, 9:01 am, Chris Hanks christopher.m.ha...@gmail.com wrote: 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 seen athttp://docs.heroku.com/background-jobsandhttp://docs.heroku.com/delay..., 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 24 (that's where the slider stops on their Resources page). The jobs being delayed won't be created faster than one every 30 seconds, so I assumed the first worker would spin up and grab the first job, then when the second job gets queued, a second worker would start, grabbing the second job, and so on. Each job would process in it's own worker, which would then get shut down when the job completes. One worker running three jobs that take a total of fifteen minutes to process should get charged the same as three workers running one job each for five minutes. If I'm mistaken, let me know. Thanks, Jim On Jan 20, 4:57 pm, Keenan Brock kee...@thebrocks.net wrote: Also a thought. You will need to introduce a lag when you are determining if you need more or less delayed job workers. Otherwise you will spin up too many DJs too quickly. And add/remove them very often. Incurring extra charges. Smugmug spoke about this when they were talking about their on demand photo processors a few years back. --Keenan On Jan 20, 2011, at 6:06 PM, Pedro Belo pe...@heroku.com wrote: 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 exception? On a side note, if it helps you can call heroku workers passing relative values, like +3, -1, etc. On Thu, Jan 20, 2011 at 12:00 PM, rubynoob mysmilecent...@gmail.com wrote: 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 = Heroku::Client.new(ENV['HEROKU_USERNAME'], ENV['HEROKU_PASSWORD']) myapp = heroku.config_vars(ENV['HEROKU_APP'])[HEROKU_APP] worker_count = WorkerCount.find(1) # now I'm storing the current number of active workers in a table that will always only have one record. workers = worker_count.workers qty = workers + 1 worker_count.workers = qty worker_count.save heroku.set_workers(myapp, qty) end In the heroku console, this runs smoothly until I try the last line, to which I get this error: TypeError: can't convert RestClient::Payload::UrlEncoded into String This line is formatted the same as LostBoy's workless gem, the autoscaling tree of delayed_job, and Heroku-Delayed-Job-Autoscale. I must be missing something obvious (typical newbie, huh?) ;) Thanks again for any help, Jim On Jan 20, 9:16 am, Peter Haza peter.h...@gmail.com wrote: 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 this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com.
Re: My (flawed?) attempt to add or subtract workers via Heroku API.
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 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 = Heroku::Client.new(ENV['HEROKU_USERNAME'], ENV['HEROKU_PASSWORD']) heroku.set_workers(ENV['HEROKU_APP'], +1) Thanks, everyone! Jim On Jan 21, 10:07 am, rubynoob mysmilecent...@gmail.com wrote: @Pedro: Here's a link to the stack trace:https://docs.google.com/document/d/1ntWg7PKgyOnSmAVkURW00O5i_LEDFdRsc... 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 to introduce a lag as Keenan suggests. Thanks, Jim On Jan 21, 9:01 am, Chris Hanks christopher.m.ha...@gmail.com wrote: 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 seen athttp://docs.heroku.com/background-jobsandhttp://docs.heroku.com/delay..., 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 24 (that's where the slider stops on their Resources page). The jobs being delayed won't be created faster than one every 30 seconds, so I assumed the first worker would spin up and grab the first job, then when the second job gets queued, a second worker would start, grabbing the second job, and so on. Each job would process in it's own worker, which would then get shut down when the job completes. One worker running three jobs that take a total of fifteen minutes to process should get charged the same as three workers running one job each for five minutes. If I'm mistaken, let me know. Thanks, Jim On Jan 20, 4:57 pm, Keenan Brock kee...@thebrocks.net wrote: Also a thought. You will need to introduce a lag when you are determining if you need more or less delayed job workers. Otherwise you will spin up too many DJs too quickly. And add/remove them very often. Incurring extra charges. Smugmug spoke about this when they were talking about their on demand photo processors a few years back. --Keenan On Jan 20, 2011, at 6:06 PM, Pedro Belo pe...@heroku.com wrote: 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 exception? On a side note, if it helps you can call heroku workers passing relative values, like +3, -1, etc. On Thu, Jan 20, 2011 at 12:00 PM, rubynoob mysmilecent...@gmail.com wrote: 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 = Heroku::Client.new(ENV['HEROKU_USERNAME'], ENV['HEROKU_PASSWORD']) myapp = heroku.config_vars(ENV['HEROKU_APP'])[HEROKU_APP] worker_count = WorkerCount.find(1) # now I'm storing the current number of active workers in a table that will always only have one record. workers = worker_count.workers qty = workers + 1 worker_count.workers = qty worker_count.save heroku.set_workers(myapp, qty) end In the heroku console, this runs smoothly until I try the last line, to which I get this error: TypeError: can't convert RestClient::Payload::UrlEncoded into String This line is formatted the same as LostBoy's workless gem, the autoscaling tree of delayed_job, and Heroku-Delayed-Job-Autoscale. I must be missing something obvious (typical newbie, huh?) ;) Thanks again for any help, Jim On Jan 20, 9:16 am, Peter Haza peter.h...@gmail.com wrote: I've done autoscaling of workers here:https://github.com/phaza/Heroku-Delayed-Job-Autoscale
Download rate 260 KB/s
I have a rails app installed on Heroku. It uses the 1 dyno free plan. I have measured the download rate with the download of a static file (200KB) from the rails public folder. The result is 260 KB/s. Are there better higher download rates in the paid plans? Best regards Oliver -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Question on shutting down Workers
Hi - I'm rigging up my own auto-scaling solution for workers. My plan to shut a worker down when it's not needed is to set $exit = true when there are no jobs left for it to do. As you can see (https:// github.com/collectiveidea/delayed_job/blob/v2.1.3/lib/delayed/ worker.rb#L74-92) this will simply end the rake jobs:work task just as if I had (for example) hit Ctrl+C. My question is, will Heroku recognize that the worker process has ended and stop charging my account when this happens? Or do I have to actually hit the Heroku API to shut it down? I'd prefer to use $exit if possible, since that will ensure that the current worker (the one with no jobs available) shuts down, whereas if I tell the Heroku API to decrement my worker count by 1, and I have multiple workers running, it could kill one of the other ones mid-job. Thanks! Chris -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Download rate 260 KB/s
I believe the charges for an additional dyno(s) are usage based so it would be a relatively cheap experiment to add a dyno and do a test. I could be wrong in that there may be some flat charge in going from a free plan to a paid but I don't remember that being the case - it would be documented somewhere on the Heroku site. So add a dyno check the dl rates and then remove the dyno or better yet keep it in place for a month and enjoy the immediate response vs the delayed response of a first page hit (after an idle period of some minutes) while the single dyno spins up. A paid plan keeps the dynos spinning and available. On Jan 25, 11:46 am, obruening ollibruen...@googlemail.com wrote: I have a rails app installed on Heroku. It uses the 1 dyno free plan. I have measured the download rate with the download of a static file (200KB) from the rails public folder. The result is 260 KB/s. Are there better higher download rates in the paid plans? Best regards Oliver -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Download rate 260 KB/s
Hi Oliver, For many static files, we are using amazon s3 / cdn That may work for you as well. --Keenan On Jan 25, 2011, at 2:30 PM, Dennis wrote: I believe the charges for an additional dyno(s) are usage based so it would be a relatively cheap experiment to add a dyno and do a test. I could be wrong in that there may be some flat charge in going from a free plan to a paid but I don't remember that being the case - it would be documented somewhere on the Heroku site. So add a dyno check the dl rates and then remove the dyno or better yet keep it in place for a month and enjoy the immediate response vs the delayed response of a first page hit (after an idle period of some minutes) while the single dyno spins up. A paid plan keeps the dynos spinning and available. On Jan 25, 11:46 am, obruening ollibruen...@googlemail.com wrote: I have a rails app installed on Heroku. It uses the 1 dyno free plan. I have measured the download rate with the download of a static file (200KB) from the rails public folder. The result is 260 KB/s. Are there better higher download rates in the paid plans? Best regards Oliver -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en. -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Question on shutting down Workers
Alright, that makes sense. Thanks, Adam. On Jan 25, 11:12 am, Adam Wiggins a...@heroku.com wrote: I understand what you're trying to do, but this won't work. Heroku will try to keep your workers alive no matter what; when it exits it will change state to crashed and try to restart once, then again every ten minutes. The full crash policy is described here: http://docs.heroku.com/ps#crashed-process-restarts If you want to change the number of running workers, you need to use the Heroku API. Adam -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
pg:reset with shared database failing
I'm getting a rather unhelpful error message when I try resetting my shared
database. I'm using v1.17.10 of the gem.
heroku pg:reset --db SHARED_DATABASE_URL --app (my app name)
... ! Internal server error
I know that the post to /apps/#{app_name}/database_reset in
Heroku::Client#database_reset is returning a 500 error with no body, so I'm a
bit stuck.
Has anyone seen this, or know what's up?
--
You received this message because you are subscribed to the Google Groups
Heroku group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/heroku?hl=en.
Re: Understanding DATABASE_URL vs. SHARED_DATABASE_URL
the SHARED_DATABASE_URL is set because all apps on Heroku come with a share database. It is not used by itself. The DATABASE_URL is the URL used by all tools. You can ignore the SHARED_DATABASE_URL in this case. ORen On Tue, Jan 25, 2011 at 3:54 PM, Wes Gamble we...@att.net wrote: I have a Heroku Rails app. that I wanted to point to another DB (used by a different Heroku app.), so I forced it's DATABASE_URL to a specific value (I am aware that Heroku _officially_ doesn't guarantee that that DATABASE_URL changes out from under the app.). This app. has a SHARED_DATABASE_URL value that is different from the value for DATABASE_URL. I notice that when I use the pgbackups add-on to do a backup, the DATABASE_URL is getting backed up, which is what I want. 1) Does the SHARED_DATABASE_URL actually matter if my DATABASE_URL value is different? 2) Should I force the SHARED_DATABASE_URL value to be the same as my DATABASE_URL value? 3) Why does pgbackups back up the DATABASE_URL instead of the SHARED_DATABASE_URL? Thanks, Wes -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.comheroku%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/heroku?hl=en. -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
rake db:migrate appeared to start migrating from the very beginning on two different apps.
Today, I ran my standard task to push changes to two different Heroku apps. As part of this task, I issue a: heroku rake db:migrate In both cases, the database started migrating from the very first migration. This, of course, doesn't make sense unless the schema_migrations table were empty or something, which shouldn't have been the case. Has anyone else complained about this today? After restoring the DBs in question up from my local installation using taps, I didn't see this behavior again. Wes -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Automated database backups to S3 using AWS-S3 gem
I'm already familiar with another solution for automatically backing up your Heroku database to S3 using the fog gem called bakkuappu. However, I'm stuck with AWS-S3 because I use Paperclip, and so whipped up a quick cron job that can be hooked into Heroku to automatically create a daily pg_dump backup of your database on S3. Figured I'd toss it out there in case anyone else could benefit from it: http://librarymixer.posterous.com/40960547 -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: rake db:migrate appeared to start migrating from the very beginning on two different apps.
This happened again to me. I verified that: - the schema_migrations table was full of data - that a Gemfile change didn't prompt this. For whatever it's worth, here is the relevant portion of my Ruby script for pushing my app to heroku: #Push to Heroku system 'git push heroku' #Migrate the DB for the main application system 'heroku rake db:migrate' I have the DB backups in place to recover from this, but it is very disconcerting. I'm trying to think of a reason why the schema_migrations table might not be available after the 'git push heroku' call. Should I make the script sleep for a couple of seconds? Wes On 1/25/11 6:27 PM, Wes Gamble wrote: Today, I ran my standard task to push changes to two different Heroku apps. As part of this task, I issue a: heroku rake db:migrate In both cases, the database started migrating from the very first migration. This, of course, doesn't make sense unless the schema_migrations table were empty or something, which shouldn't have been the case. Has anyone else complained about this today? After restoring the DBs in question up from my local installation using taps, I didn't see this behavior again. Wes -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en. -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
