Re: PGError: ERROR: relation users does not exist
I'm not sure if this is it, but I've had problems with db tables that are used in initializers. It seems the whole rails environment is initialized before a migrate, so that the not-yet-existing tables/columns cause the process to halt. I put the relevant parts in the initializers within begin .. rescue .. end structures. Hope that helps. --~--~-~--~~~---~--~~ 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: Problems with pids
Hi Adam, I think a uniform, easy-to-use, reliable way of doing background processing would be a killer feature on Heroku, and I have come to realize that the lack thereof is a major weakness of Rails. The code I have been working on in a webservice backend for a mobile app, a simple chat server with some extra functionality. Not the most common Rails use case. I was attracted by Rails' RESTful API, but discovered some drawbacks, of which the difficulty of doing asynchronous processing was the largest. It would be helpful if you could tell me more about exactly what you're trying to do, so that we can include your requirements into our design. I came up against three different needs of background tasks: 1) Perform calls to a remote web service in the background so as not to block main app; this task can take up to 30-60 secs, and basically unlimited parallel tasks should be allowed. 2) Run a background task that wakes up every x seconds (15 in my case) to remove users that have lost connection from the server from the db. There can be only *one* of there tasks. 3) Run a background task that performs jobs based on requests that have been stored in the db. In my case, I let this process sleep for 2 seconds before checking for jobs that have been stored in the db. Only *one* of these as well. Because the requirements of each of these were different, I couldn't find a single plugin that would do it all. (Workling for example wouldn't let me do 1, as there can be only one worker of a particular kind.) Some frameworks looked good, but required too much configuration and didn't work out of the box. I ended up implementing each of the above using the Spawn gem. But then I ran into problems with spawned processes surviving between invocations of the Rails environment, so that I got too many background tasks interfering with each other. And so I implemented a scheme to keep track of pids and only spawn new processes when necessary, kill processes when needed etc. Unfortunately, as I described in my first post, this didn't work on Heroku, for the reasons that you rightly pointed out. So, if you can come up with something that can let me do each of 1, 2, 3 above, in an easy way, I would be more than satisfied! I would like to be able to create workers, and specify the minimum and maximum number of each that should be available. Some should be monitored so that, if they die, a new one should be spawned immediately. I would also like timing to be built in (something like rufus-scheduler). Ability to work off a job queue on the db should also be part of the deal. Thanks for considering my needs! /Felix --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Problems with pids
I'm spawning a couple of background processes in my Rails app, and have inserted checks to see if old processes (possibly from earlier runs of the app) are still around. If there are old processes, the app either kills them or lets them carry on with their work and desists from spawning even more processes. I use something like Process.kill(0, pid) to check if old processes are still alive. Unfortunately, on the Heroku server this call always indicates that the process is dead. In short, I have no access to processes that I once spawned, although I have their pid stored in the db. I can neither kill them nor reliably find out if they are alive. This has lead to situations where I had to redeploy to a new Heroku process to get rid of background processes hanging around in the background. For my app to work, I simply need to be able to spawn, track and kill processes. Is there a workaround, or do you envision one for the future? I understand there are various security considerations, but it's not that complicated: let processes with the same uid do what they will with each other. For now, I've had to move back my app to my old server, which is otherwise so much less sexy than Heroku. Felix --~--~-~--~~~---~--~~ 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: Initilizers called 4 times!
Ok, I tested this further by running Thin locally. Thin running on my system *never* calls the scripts in config/initializers more than once, at startup (even in development mode). Please, if you have any idea what causes Heroku to behave in this way (calling the initializers up to four times at startup time, and sometimes at random times while the app is running), let me know if this is a bug or if I need to take special precautions. This is my only beef with heroku at the moment, and my app is ready for testing once this is resolved. I'm reluctant to try out various tricks to make this work before I have confirmed whether this is behavior that could be classified as a bug on Heroku's part or not. Any feedback would be very much appreciated. /Felix 2009/2/24 Felix Holmgren felix.holmg...@gmail.com: Hi! I just found out that my initializers (in config/initializers) get called four (4!) times when I run heroku restart. . . . --~--~-~--~~~---~--~~ 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: Initilizers called 4 times!
Hi again, Ok, I guess this is obvious. Heroku is starting a small Thin cluster running my code, and each Thin instance runs the initializer scripts. Sorry for not realizing this obvious fact before... However, I'd still appreciate it if anyone knows of streamlined ways of avoiding ending up with many spawned background processes! /Felix --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Initializers interfering with migration
I added a table (Debug) to my app, and created rows in it in an initializer script. When I pushed it to Heroku I couldn't run rake db:migrate, because Heroku first wanted to initialize the environment, and since the initialization tried to access the table that was about to be created, the migration failed. Very frustrating. I had to first comment out the line that used the table, push to heroku, then migrate. I have not encountered this problem before, neither locally nor on my former host. Unless I have failed to see something obvious (which is quite likely), I would say this ranks as a bug. Please enlighten me. Also, what is the proper thing to do after pushing code that adds new migrations? Running db:migrate? Or db:schema:load? (Having first dumped schema.rb locally and checked it in.) Is it ever necessary/proper to execute db:drop or db:create? The db migrations have been the trickiest part of my Heroku experience so far. Felix --~--~-~--~~~---~--~~ 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: error: failed to push some refs
Ok, I realized I had to do git push -f heroku I'm a git newbie... /F --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
