2

We have a grails app deployed in heroku cedar, our app takes more than 60 seconds to start, and according to heroku:

A web process took longer than 60 seconds to bind to its assigned $PORT. When this happens, the dyno’s process is killed and the dyno is considered crashed

we reduced dependencies as posible but in some occasions the startup takes more than 60 seconds, so our app is stopped by heroku.

Do you know some way to avoid this?

solaechea
  • 89
  • 11

3 Answers3

4

I have a nice solution for this problem: I forked the Grails buildpack and added a bit of code that forces Jetty to bind to the $PORT early, so that Grails can take all the time it wants to start up; during the Grails startup time, requests simply fail with a 404 error, but at least the app starts reliably.

https://github.com/funfork/heroku-buildpack-grails-earlybind

To use it:

heroku config:set BUILDPACK_URL=https://github.com/funfork/heroku-buildpack-grails-earlybind

And if you need to force a slug recompile (ensure that you have no commit pending first):

git commit --allow-empty -m "empty commit"
git push heroku master

And here you go!

gpothier
  • 850
  • 6
  • 12
1

There are two things you could do. The first would be to try to explicitly set your dependencies, so that dependency resolution doesn't take as long. See Pete's answer on slow Grails start-up.

Something you could try that is Heroku-specific would be to use the new 2X Dyno Size, which gives you 1024MB of RAM instead of 512MB (but note that they are $0.10 per hour instead of $0.05 and no longer fall under the free tier).

Finally, since Heroku is looking for a binding to $PORT, you could listen on $PORT and queue any requests until the app is fully started.

Community
  • 1
  • 1
Benjamin Manns
  • 9,028
  • 4
  • 37
  • 48
  • See below: I have a fork of the Grails buildpack that solves this issue: https://github.com/funfork/heroku-buildpack-grails-earlybind – gpothier May 10 '13 at 14:07
1

I experienced the same with a Grail's app. One of my apps boots correctly, but then I deployed another one and had this problem, although their dependencies configuration was very similar.

I solved it by removing some js plugins in BuildConfig.groovy (jquery, jquery-ui, twitter-bootstrap and lesscss-resources) and adding this resources manually.

Locally, this reduced boot time from 20 to 13 seconds more or less (always talking about the first boot, in interactive mode successive boots are very fast). Take into account that I also create-drop tables and bootstrap some data, although avoiding this didn't solved my problem until I removed mentioned plugins.

It's also interesting how my other app manage to start in time in heroku, having all of the plugins.

Tomas Romero
  • 8,418
  • 11
  • 50
  • 72