We are running our grails probject with run-app. The first time a page is requested, there is a delay. Every time after that, however, the page loads quickly.
The most obvious explanation I can think of is that the page hasn't been compiled yet. Is there a way to induce compilation or whatever else is causing the delay?
I hope you are only using "run-app" in development and not in production.
If you want to pre-compile the GSPs then use "run-war".
Be aware though, changes to the GSP will not be detected and you will have to restart the application or make changes to your configuration to enable dynamic recompile.
To enable dynamic recompile of GSPs when running as a WAR modify your Config.groovy with the following:
grails.gsp.enable.reload = true
grails.gsp.view.dir = "/path/to/WEB-INF/"
I can't stress enough, if this isn't in development, and instead is production, deploy your application as a WAR file.
Related
I'm working on a rails app where we want to allow the user to use an admin tool to create new themes. The admin tool is a separate application and communicates with our main application through a database. My problem is that I've written custom Sass extensions to load our data into our style sheets, but once that is done, I am unable to recompile the assets in our production environment.
So far I've seen two possibilities for this:
1.Increment the version of config.assets.version. So I have this code:
MyApp::Application.assets.version =
(MyApp::Application.config.assets.version.to_i + .1)
From what I've read incrementing this should cause the assets to recompile, but it seems to only work when it is incremented by hand and the server is restarted.
2.Create a compiler and tell it to clean up the old assets and recompile them:
compiler = Compass::Compiler.new(
Rails.root.to_s,
Compass.configuration.sass_path,
Compass.configuration.css_path,
{:sass => Compass.sass_engine_options} )
compiler.clean!
compiler.run
With this method, however, I run into the problem that the Sprockets::Index.expire_index! method raises an error when I try to create a new compiler.
Yes, I do understand that I can set the assets to recompile on every request, but the performance hit is not something we want. Also, since this is a theme, the data should not be changing often, so we only need to recompile when the admin chooses to save the new theme.
So, finally, my question is: Are there any other possible methods to do what I want? Or am I going down the right path, and if so, where am I going wrong?
EDIT:
I forgot to mention that since we are using Sass functions to change the values of the stylesheets, even if I do turn on the option to compile in production, it won't work. Since the actual stylesheets will never change.
Rails has a Rake task that does asset compilation for you. You should run it once every time you deploy your application to your production environment.
rake assets:precompile
The compiled assets are output to public/assets. For more details, check out the Rails Asset Pipeline Guide.
I have a Rails 3 based CMS that allows users to create and modify layouts and views. These layouts and views are the same ones built into the framework, only backed by a model for some additional capabilities. The problem I would like to address is that these template files are cached as soon as they are accessed on the public end, so it is not possible to see changes in the layouts or views unless the server is restarted. This does not occur in development mode where caching is disabled, but obviously turning off template caching in production wouldn't be great for performance. Clearing memcache doesn't seem to do the trick. Is it possible to programatically clear out the layouts and views cache in production, perhaps with something like reload! like we have in the console? Or am I stuck having to restart Passenger every time someone wants to tweak one of these layouts or views (perhaps using the approach in this thread: Rails Cache Clearing)?
Please note that I am not referring to clearing the page and action caches, which the public pages rely on and works just fine.
José Valim has a great chapter in "Crafting Rails Applications" that goes over this topic. Here is an approach that uses Mongoid to store view templates. If you build your own view Resolver, then you just need to call #clear_cache on the resolver instance when someone saves a new template in the database.
this configuration may help (at least it worked* for me):
config.action_view.cache_template_loading = false
works in rails 3
There's just a slight difference in rails 2:
config.action_view.cache_template_reloading = false
In production mode, it's normal to require a restart to implement rails code changes, which is what you are doing by editing the layouts and views. It sounds like you're really operating in a development environment if you are editing the application code while it's running. In production mode I don't know of a way to refresh Passenger without touching restart.txt or restarting the web server.
EDIT: You should be able to touch tmp/restart.txt programmatically from within your app. This should tell Passenger to reload on the next request.
At work, we have a situation where when
script/server
is run, then all the controller code is cached. This is to speed up the
development server. But that will mean that whenever we change the
controller code, we need to restart the server.
So we can turn off the caching of controller code all together. But
can't there be mechanism that is similar to the inclusion of javascript
foo.js?1275647624 <--- UNIX timestamp
which is to use the cached version as long as there is no code change,
but recompile it when there is code change?
Maybe because we use HAML and SASS a lot, loading some page (such as the
homepage of the site) can take 40 seconds on the dev environment and it
is quite long.
By default Rails will reload your classes for every request in the development environment. This should ensure that any changes are picked up. Classes are usually only cached when running in the production environment, or possibly if you have a staging environment set up.
Obviously I don't know your application, but 40 seconds to load a home page in development sounds like a long time. Are there any errors in the log?
I posted this very same item on SERVERFAULT, but got no reply. So here goes:
I'm currently in the process of finishing up a Rails application. I am using Warbler to package it up as a ".war" file and am using GlassFish to deploy it. I do this because the application is to be distributed to companies for in-house use. Arguably i could/should have used another framework to develop an application of this nature, however, I chose ease/speed of development over deployment hassle.
That said, I've got the setup working reasonably well on my development machine. However, I'm curious as to how to go about automating environment initialization. In other words, I need to figure out how to ensure that all DBs, files,etc. are configured upon deployment.
All of the examples I've seen thus far assume you're running your IDE on the system to which you wish to deploy and they have you run your rake tasks manually before deployment. However I need to simply give the end user the ".war" and be able to run all rake tasks upon application deployment/launch.
Can someone point me in the right direction regarding this? FWIW there is nothing in the Glassfish manual about environment initialization etc. -- then again, I don't suppose I should expect them to cover every single aspect of deployment.
Best.
Depending on your database requirements you can embed Derby within the Glassfish environment. You can easily create a blank/default database and then put that clean version in each Glassfish environment you have to set up.
I'm not sure what else you need to configure and initialize, but I'd say that if you can, script it up, either with some rake tasks. Embedding Derby takes care of database startup and initialization. Remember that a war file is just a zip file, so adding config files via a script shouldn't be so hard. You can use rails initializers (/config/initializers/) to load up yml files for configuration or whatever you need to do as the app starts up.
You won't be able to have the intializers create the schema in the database, but you could have them check for default seed data and put it in if it isn't there.
You should be able to access any part of the file system that Glassfish and the JVM can access. I don't know much about Glassfish but the only problems I've had with jruby rails apps on Tomcat were related to relative paths being relative to where the startup script was called from, and not always relative to the installation root. This could probably be solved with the right startup scripts in Tomcat or setting the appropriate start-in folder, I just haven't had a need to dive in to that very much.
I'm new to Ruby on Rails and am creating a test application. So far, it's working, but when I make some minor changes to my views, the page doesn't change.
My problem may be related to this question, but I'm not sure what is meant by setting the date and time in the VM. My code is on a remotely hosted server, so I assume it would use the system time of that machine.
Is there a caching issue here? What can I do about it?
If you don't have control over the server environment yourself (no shell access, etc.), you can set the following at the top of config/environment.rb:
ENV['RAILS_ENV'] = 'development'
Development doesn't cache much, so while it's slower it's much nicer to develop in.
You'll still need to restart your app after making changes to anything outside the app/ folder though (configs, plugins, etc.).
You need to restart your Rails app (or Apache if you are using Passenger) if you are in production mode!