I have created grails application and uploaded it in heroku.
If I use 'heroku scale web=1' everything looks OK. But if I run 'heroku scale web=2', some static resources disappear.
From logs I can figure out, that all static resources from web.2 dyno are missing. But this dyno is started without any errors.
How can I resolve this problem?
https://github.com/grails-plugins/grails-resources/pull/11
According to the owner of the resources plugin, Marc Palmer, they're ignoring a check for old references to static resources.
So, this manifests itself as a load balancing issue that you would have on any system if you're not using sticky load balancing (which is the case with Heroku). Here's what's happening in the Heroku case:
From my research, the best practice is to declare your resources in a resources file.
See the following:
http://grails-plugins.github.com/grails-resources/guide/3.%20Declaring%20resources.html
This will tell the app server at boot time that a resource exists up front, avoiding the adhoc loading process.
For example, as in my previous email, a MyResources.groovy would look like:
So, you can use either of the two methods -- explicitly specify resources, or use adhoc loading (add the following to your Config.groovy: )
It essentially disables adhoc resource processing.
All assets which are in your slug (your git push essentially) should be present on all dynos. Are these assets that have been uploaded? If so, Heroku has an effectively read-only file system (http://devcenter.heroku.com/articles/dyno-isolation#ephemeral_filesystem), so you need to ensure that these assets are going to something external such as Amazons S3.
http://grails.org/plugin/amazon-s3
I had similar issues with image files that cannot be directly defined in ApplicationResources.groovy. I found a workaround for this one, though:
Add a CSS file to ApplicationResources.groovy that has multiple class definitions for all the assets you need to load like this:
And in ApplicationResources.groovy define the following:
Now the Resources plugin has already those paths ready for the images when the module that contains the CSS file is loaded from a GSP view, or if the images are referenced dynamically from JavaScript etc.
Rather hacky but it works. Tested this in Heroku with 2 dynos.